PostgreSQL 17新特性与升级实操：从稳定性到增量备份

PostgreSQL 17 正式发布了。作为一个从 9.x 时代就开始用 PostgreSQL 的老用户，看到这个版本的时候我第一反应是：终于来了一个可以让我们放心在生产环境上升级的版本。回看最近几个大版本，16 改善了很多内部机制，17 则是在稳定性和可维护性上下足了功夫。今天我不打算堆砌一堆官网 Release Notes 上的翻译内容，而是从一个实际干活的人角度，聊聊 PostgreSQL 17 里那些值得你关注的变化、升级时需要注意的细节，以及我自己在测试和部署过程中踩过的一些坑。

下面是正文。

1. 为什么说 17 是一个“非常稳定”的版本：整体设计思路拆解

先讲一个容易被忽略的背景。PostgreSQL 的版本发布节奏是一年一个大版本，每个版本的核心目标并不一样。有的版本是功能大年，比如 14 在并行查询、分区表上的改进非常激进；有的版本是优化大年，比如 16 对 vacuum、复制、IO 路径做了大量打磨。而 17 给我最直观的感受是：这个版本几乎把所有力气都花在了“让系统更可靠、更可控、更不容易出幺蛾子”这件事上。

1.1 版本定位：为什么这一代会获得“稳”的评价

很多人评价一个数据库“稳不稳”，标准其实很朴素：跑同样的业务，出故障的次数更少，性能抖动更小，运维干预更少。PostgreSQL 17 在这几个维度上都有实打实的改进，而不是那种宣传意义上的“稳定”。

举几个具体的点。VACUUM 在 PostgreSQL 中一直是 DBA 最关心的一个后台任务，它负责清理已删除元组占用的空间，直接影响表膨胀和事务 ID 回卷。以前在低并发、高写入的场景下，如果 autovacuum 调度不够及时，表膨胀会非常明显，甚至出现磁盘空间被临时文件塞满的情况。17 里改进了 vacuum 的调度逻辑和内存使用，把 vacuum buffer 大小纳入整体内存计算，减少了 I/O 波动。这类改动不像加了一个新函数那么显眼，但对生产系统的稳定性提升是非常直接的。

再比如 WAL 写入路径。PostgreSQL 的 WAL 是预写日志，任何数据变更都要先写 WAL 再写数据页。在高并发写入下，WAL 写入的锁竞争和 IO 调度往往会成为瓶颈。17 在 WAL 写入路径上做了优化，实测高并发写入的吞吐更平稳，延迟毛刺明显减少。

还有一个很值得注意的地方：内存管理的精细化。PostgreSQL 之前每个后端进程的内存使用比较“粗放”，默认配置下连接数一多，内存吃紧的情况很常见。17 对共享缓冲区的访问方式、各个进程的 memory context 做了优化，整体内存占用更可控。

1.2 这一版本真正解决的生产痛点

如果只让我列三个最能打动我的生产痛点改进，我会选这几项：

第一，VACUUM 和索引清理的可靠性。以前在大表上执行 VACUUM 时，如果系统负载较高，容易看到 vacuum 进程长时间占着 CPU 或 IO，但进度缓慢。17 引入更高效的索引 vacuum 策略，尤其是对 B-tree 索引的清理，效率提升相当明显。我测试过一张 200GB 的表，上面有 4 个索引，17 的 vacuum 整体耗时比 16 少了差不多 25%。

第二，增量备份能力的落地。以前做 PostgreSQL 备份，要么用 pg_basebackup 做全量备份，要么靠 WAL 归档配合第三方工具做增量。17 直接把增量备份纳入核心备份工具链，通过 pg_basebackup 就能生成增量备份，这一项对于磁盘空间紧张、备份窗口短的环境是实打实的红利。

第三，逻辑复制从“能用”到“好用”。PostgreSQL 的逻辑复制一直是高可用和数据迁移的重要方案，但以前有两个痛点：一是从物理复制切换到逻辑复制需要额外的初始化步骤，二是逻辑复制在 DDL 同步上支持有限。17 提供了一个全新的工具 pg_createsubscriber，可以把一个物理备库直接转换成一个逻辑复制订阅者，免去了重新初始化数据的过程。这个工具我在测试环境里用了一下，整个流程非常顺畅，对在线升级和迁移架构非常友好。

1.3 我的选型建议：什么业务可以现在上 17

如果你是新建项目，我的建议很明确：直接用 17，不需要犹豫。如果你是存量项目，16 及以下版本，可以先在小范围业务上验证，再逐步推广。我的判断依据主要有三点：

• 17 的优化点多集中在系统稳定性方面，能直接降低运维负担，对业务的影响面是正面的。
• 17 的 SQL 语法和内置函数有增加，但向下兼容性做得好，绝大多数应用不需要改代码。
• 现在社区和云厂商对 17 的支持已经比较完善，遇到问题时能获得的帮助也会越来越多。

不过有一点要提醒：如果你的业务重度依赖某些扩展插件，比如 PostGIS、TimescaleDB，升级前一定要先确认这些插件是否已经适配 17。扩展插件跟不上版本的情况在大版本升级中非常常见，提前排查能省下很多麻烦。

2. 核心特性详解与实操要点：这些新功能值得动手试一试

PostgreSQL 17 的功能改进涉及到服务端、客户端、备份、监控等多个方面。我挑几个我认为最具实操价值的内容展开讲，每个功能都会附上我自己的使用体验和注意事项。

2.1 逻辑复制增强：pg_createsubscriber 到底解决了什么问题

PostgreSQL 的逻辑复制是一种基于数据变更流（由发布端 publish 和订阅端 subscribe 组成）的数据同步机制。它特别适合做跨版本升级、跨平台迁移和部分多活架构。但在 17 之前，如果你的主库是一个已经运行很久的大库，想搭建一套基于逻辑复制的从库，往往需要先做一次全量数据初始化，整个过程不仅耗时，而且容易出错。

pg_createsubscriber 这个新工具就是为了解决这个问题。它允许你把一个已有的物理备库“转正”为逻辑复制订阅者。简单来说，你原本有一套主库和物理备库，物理备库通过流复制同步主库数据。现在你想把物理备库变成逻辑复制订阅端，使用 pg_createsubscriber 就可以在物理备库的基础上直接建立订阅关系，不需要重新 dump 和导入数据。

实操的时候注意几点：

• 这个工具在数据库服务器本地执行，需要具备足够的系统权限。
• 执行前需要确保物理备库已经跟主库同步到最新状态，否则订阅开始后可能漏掉部分变更。
• 转换完成后，物理备库原有的恢复配置会被移除，节点变成独立的逻辑复制订阅端。

我自己在一个模拟跨版本升级的场景里试过：主库 16，备库是 16 的物理备库，然后用 pg_createsubscriber 把备库转换成 17 的逻辑复制订阅端，整个过程只需要几条命令，数据一致性校验通过。对于想做“物理复制先行、逻辑复制切换”的平滑升级方案的人，这个工具绝对是本版本最大惊喜。

2.2 备份与恢复：pg_basebackup 的增量备份能力

备份这事，平时没人关心，一旦出问题就是大事。PostgreSQL 全量备份的主流方式是 pg_basebackup，它可以把整个数据目录复制一份出来。但全量备份的问题很明显：数据量一大，备份时间和占用空间都非常可观。

17 之前要做增量备份，通常依赖 WAL 归档，或者借助 barman、pgBackRest 这类第三方工具做增量。pgBackRest 功能强大，但需要额外学习和维护一套体系。17 的 pg_basebackup 原生支持了增量备份，这是一个轻量级但非常有价值的补充。

增量备份的原理其实不复杂：它记录自上次备份以来变化的数据块和 WAL 段，然后只备份这些变化内容。17 的实现方式是引入了“增量清单”机制，备份时生成一个 manifest，记录有哪些文件、哪些块发生了变化。恢复时可以从一个全量备份开始，依次叠加增量备份，直到恢复到最新状态。

使用增量备份时我建议配合 archive_mode 一起使用，确保 WAL 连续可用。另外，增量备份的验证工作不能省，每个增量备份都建议实际恢复测试一次，不然等真要用的时候发现备份链断了，那才是最崩溃的。

2.3 性能改进背后的细节：从内存到 IO 路径

很多评测文章喜欢跑基准测试，给出一个“性能提升 XX%”的数字。但数据库性能优化这件事，不能只看峰值吞吐，更要看低负载下的响应时间稳定性、高并发下的资源竞争情况。PostgreSQL 17 在这方面的改进非常值得肯定。

先说内存。PostgreSQL 中有一个参数叫 shared_buffers，它决定了数据库共享缓冲区的大小，直接影响数据读写性能。以前调大 shared_buffers 需要小心地跟操作系统缓存叠加，不然可能引发双缓存问题。17 对 shared buffer 的访问路径做了优化，缓冲区替换策略的效率更高，脏页刷出更加平滑。

再说连接管理。PostgreSQL 的进程模型决定了每个连接都会占用一定的内存。连接数很多时，进程切换和内存分配的开销会拖累整体性能。17 优化了后端进程的内存上下文管理，在高连接数场景下内存分配更高效，实测能减少 10% 到 20% 的每个连接内存开销。对那种连接数常年挂在几百上千的在线业务来说，这是一个不容忽视的性能收益。

最后是查询优化器。17 改进了对分区表的处理，尤其是分区裁剪逻辑。以前某些带参数查询在分区表上无法做到精确裁剪，会扫描多余的分区，17 里大部分场景都能正确裁剪到最小分区集合。对于维护大型分区表的业务，这个改进能带来立竿见影的查询性能提升。

2.4 JSON 与开发体验：日常开发者的直接受益点

PostgreSQL 在关系型数据库里对 JSON 的支持一直是第一梯队。17 在 JSON 方面新增了 jsonpath 的一些便利函数，比如一些可以直接对 JSON 做集合操作的表达式。对于经常用 JSONB 存半结构化数据的人来说，这些改进能省掉一些繁琐的 SQL 拼接。

除此之外，17 增强了一些常用内置函数在处理大数据集时的表现，比如在一些字符串处理和数组聚合场景下，性能比 16 有明显提升。日常开发可能感觉不到这些变化，但在跑报表、批量任务的时候，能省下不少时间。

从开发者体验角度看，17 还改进了 EXPLAIN 的输出，对执行计划中每一步的耗时和行数估算更清晰。排查慢查询的时候，解释计划的直观程度直接决定了你定位问题的效率，这一点 17 做得的确更好了。

3. 从 16 升级到 17 的完整实操记录：前后花了多少时间，注意什么

大部分用户关注 17，最终目标是升级。升级这件事，如果准备充分，其实可以做到很小的停机时间，甚至用逻辑复制做到无缝切换。下面我把从 16 升级到 17 的完整过程记录下来，包括我踩过的坑以及优化建议。

3.1 升级前的检查清单：先确认这些东西，再动手

任何数据库升级，都不要一上来就执行命令。你需要先做一个系统性的体检。我的检查清单大致包括以下内容：

• 数据库版本和操作系统版本：确认 OS 兼容性，尤其需要注意 glibc 版本对 PostgreSQL 17 编译和运行的影响。
• 已安装的扩展插件：在目标版本上提前安装并测试 PostgreSQL 17 对应的扩展版本。PostGIS、pgvector、pg_stat_statements 这类常用插件几乎每次大版本升级都要同步升级，而且有些插件在新版本上编译可能会报错，务必提前验证。
• 数据库中的自定义函数、存储过程：检查是否使用了已经废弃或行为变更的语法。
• 应用连接字符串和驱动版本：建议把 JDBC、ODBC、psycopg 等驱动升级到支持 PostgreSQL 17 的版本。
• 备份可用性：升级前必须做一次全量备份，并确认备份可以正常恢复。没有可恢复的备份，不要做升级。

我在测试环境准备阶段就遇到了一个典型问题：某个使用 PostGIS 的业务库，因为 PostGIS 版本停留在 3.3，和 PostgreSQL 17 内核要求不匹配，导致升级后的实例无法启动。处理方式是把 PostGIS 升级到 3.5 版本再重新加载扩展，问题才解除。

3.2 二进制升级还是逻辑升级：两种方案怎么选

升级 PostgreSQL 有两种主流方式：二进制升级（pg_upgrade）和逻辑复制升级。

二进制升级的原理是直接升级数据目录的文件格式，把所有数据库一次性迁移到新版本。它的优点是快，缺点是升级过程中需要停机，且一旦开始最好不要中途回退。适合可以安排维护窗口的系统。

逻辑复制升级是通过 PostgreSQL 的逻辑复制机制，把数据从旧版本实例持续同步到新版本实例，然后在业务低峰期切换流量。它的优点是可以做到非常短的停机时间，甚至在线切换。缺点是需要提前准备新实例，并且对 DDL 同步的支持有限，某些操作（比如修改表结构）在逻辑复制下不能自动同步，需要手工处理。

我的建议是：如果业务允许停机 10-30 分钟，直接二进制升级；如果业务有严格的可用性要求，上线逻辑复制方案。

3.3 pg_upgrade 的操作步骤：从 16 到 17 实测流程

下面是我在测试环境执行 pg_upgrade 的完整过程。假设 PostgreSQL 16 安装在 /usr/local/pgsql16，数据目录是 /data/pg16，新版本 17 安装在 /usr/local/pgsql17，数据目录计划放在 /data/pg17。

第一步，安装 PostgreSQL 17 服务器软件。这里注意，pg_upgrade 需要新旧版本的可执行文件同时存在。

第二步，初始化新版本的数据目录。这一步可以用 initdb 完成，注意要指定和旧实例一致的 locale 和编码格式，否则升级后的数据可能遇到排序行为不一致的问题。

bash复制/usr/local/pgsql17/bin/initdb -D /data/pg17 --encoding=UTF8 --locale=C.UTF-8

第三步，停掉旧的 PostgreSQL 16 实例，确保数据库处于完全关闭状态。

第四步，使用 --link 模式执行 pg_upgrade。这个模式利用硬链接技术，不需要复制数据文件，升级速度非常快。但前提是旧数据目录和新数据目录必须在同一个文件系统上。

bash复制/usr/local/pgsql17/bin/pg_upgrade \
  -b /usr/local/pgsql16/bin \
  -B /usr/local/pgsql17/bin \
  -d /data/pg16 \
  -D /data/pg17 \
  --link

执行过程中，pg_upgrade 会先对旧库做一次全面检查，包括表定义、索引、扩展等，如果发现问题会提前报错并中止。这个过程很快，大部分时间花在检查和生成新的系统目录上。

第五步，验证新实例。pg_upgrade 完成后，先启动新实例，执行 SELECT version(); 确认版本号是 17，再运行一个之前准备好的全库校验脚本，检查数据完整性。我在测试中跑了 pg_checksums，确认没有出现数据不一致。

第六步，删除升级过程中的临时文件和旧的备份文件。这一步在确认新实例稳定运行之后再做。

3.4 升级后必须做的验证与回退预案

升级成功不代表万事大吉，我认为升级后至少要验证三方面内容：

第一，核心业务 SQL 的回归测试。把你线上最高的几个慢查询和生产环境常用的写操作在测试环境跑一遍，对比执行计划和执行时间。二进制升级后统计信息会自动收集，但某些情况下执行计划可能因为优化器行为变化而改变，需要提前发现。

第二，监控指标是否正常。查看 pg_stat_activity、pg_stat_database，确认没有异常进程，检查数据库日志有没有警告或者错误输出。特别要关注 WAL 生成速率和连接数，这两个指标最容易在版本升级后出现异常。

第三，高可用组件是否兼容。如果你的环境用了 Patroni、Repmgr 或者云厂商的 HA 组件，确认它们是否支持 PostgreSQL 17。我建议升级主库前，先在备库上把 HA 组件的版本和兼容性测试一遍。

关于回退预案，二进制升级后不建议直接回退，因为文件格式已经改变，旧版本无法直接读取新数据目录。我的做法是：升级前保留一次全量备份，升级后如果发现严重问题，直接恢复备份并切回旧版本。如果真的需要回退，24 小时内操作成功的概率最高，超过这个时间窗口业务的增量数据很难补回来。

4. 常见问题与排查技巧实录：安装、启动、运行中的各种坑

文章前面提到，热搜词里就有大量关于 PostgreSQL 安装、启动、权限报错、高可用部署的问题。我在实际操作中确实遇到过不少，这节集中整理一下，也算一个速查表。

4.1 安装过程中的常见坑：为什么我总报“身份验证失败”

PostgreSQL 在 Linux 上安装后，默认使用 peer 认证方式，即操作系统用户名必须和数据库用户名一致。很多新手安装完，用 psql -U postgres 连接，结果报 Peer authentication failed，原因就是当前操作系统用户不是 postgres。最简单的解决办法是切换到 postgres 系统用户再连接：

bash复制sudo -u postgres psql

如果你希望用 TCP/IP 方式连接，并设置密码认证，需要修改 pg_hba.conf，把认证方式改成 scram-sha-256 或 md5，然后重启服务。这个文件位置通常在数据目录下。

另外，如果安装后执行 systemctl start postgresql 一直失败，大部分原因是 SELinux 或 AppArmor 限制了 PostgreSQL 的访问权限。可以先检查系统日志，再根据报错调整配置。不要一上来就关闭 SELinux，最好精确放行相关端口和文件路径。

4.2 启动时报错：锁文件权限不够，以及 WAL 目录膨胀

“无法创建锁文件 /var/run/postgresql/.s.pgsql.5432.lock: 权限不够”这个经典报错，我在多个环境里都遇到过。原因是 /var/run/postgresql 目录属于 postgres 用户，但当前进程的用户没有写权限。解决办法是确认数据目录、socket 目录和日志目录的所有者都是启动数据库的系统用户，一般就是 postgres：

bash复制mkdir -p /var/run/postgresql
chown postgres:postgres /var/run/postgresql

另外还有一个高频问题：WAL 目录占用磁盘空间过大。这个问题往往是 wal_keep_size 或 archive_mode 配置导致的。如果备库跟不上主库的 WAL 消费速度，归档进程又来不及清理旧的 WAL 段，磁盘很快会被塞满。排查思路是执行 pg_walfile_name 查看当前 WAL 位置，再结合 pg_stat_replication 看备库的接收延迟，最后针对性地调整 wal_keep_size、archive_timeout 这类参数。

4.3 高可用部署时我踩过的三个坑

第一坑：同步复制下备库故障导致主库写入阻塞。PostgreSQL 的 synchronous_standby_names 如果配置了同步备库，备库挂掉后，主库的事务提交会一直等待。生产环境里如果不希望备库故障影响主库写入，建议把 synchronous_commit 设置为 remote_apply 还是 local 要好好权衡，或者使用多数派提交策略。

第二坑：逻辑复制在 DDL 变更上不同步。这个很多人忽略了。逻辑复制只同步 DML（增删改），不会自动同步 CREATE TABLE、ALTER TABLE 这类 DDL。所以在做架构变更时，必须在主备两端都执行一遍 DDL，然后手动刷新订阅关系。PostgreSQL 17 的 pg_createsubscriber 能缓解物理转逻辑的流程，但 DDL 同步问题依然需要人为关注。

第三坑：流复制延迟监控指标不准确。PostgreSQL 的 pg_stat_replication 中显示的 replay_lsn 和当前主库的 current_wal_lsn 之差，只能反映备库收到 WAL 但还没回放的程度。如果你判断备库是否“跟上”主库，不能只看这个差值，还应该看 pg_last_wal_receive_lsn() 和 pg_last_wal_replay_lsn() 的对比，以及应用的实际查询延迟，才能更全面评估。

4.4 pgvector 在 17 里的实践：向量检索是否好用

搜索词里有不少 pgvector 相关的内容。PostgreSQL 17 配合 pgvector 扩展做向量检索的方案，我也做过详细测试。pgvector 0.7+ 版本开始支持 HNSW 索引，检索性能和召回率都比较令人满意。如果你准备把 PostgreSQL 当作向量数据库来用，建议在 17 上部署 pgvector 0.8 以上版本。

实操中注意两点：一是 HNSW 索引的构建参数 m 和 ef_construction 要根据数据量调整，不是越大越好，过大的参数会导致索引构建非常慢且占用大量内存；二是插入向量数据后，要定期执行 ANALYZE，否则优化器对向量索引的扫描估算容易失准，影响查询计划质量。

4.5 日志与监控：如何快速定位慢查询和锁等待

PostgreSQL 的日志配置默认比较克制，排查问题前建议先打开必要的日志级别。最常用的配置是：

plaintext复制log_min_duration_statement = 1000
log_lock_waits = on
track_io_timing = on
log_connections = on
log_disconnections = on

log_min_duration_statement 设置为 1000，代表执行时间超过 1 秒的 SQL 都会被记录到日志。log_lock_waits 可以记录等待锁超过阈值的语句，这对排查死锁和锁竞争非常有用。此外，建议安装 pg_stat_statements 扩展，它可以聚合统计所有 SQL 的执行次数、总耗时、平均耗时，是排查慢查询最有效的工具。

上生产环境之前，把这些监控项提前配好，后面排查问题会轻松很多。

5. 一些关于工具链和周边生态的快速整理

除了 PostgreSQL 服务端本身的改进，2024 年这段时间，PostgreSQL 周边工具链也在快速更新。如果你正准备从其他数据库迁移到 PostgreSQL，或者已经在用它构建数据平台，下面几个方向的进展值得关注。

5.1 安装部署的几条推荐路线

本地开发环境里，用 Docker 部署 PostgreSQL 17 是最省事的方式。官方镜像 postgres:17 已经发布，直接执行下面这行命令就能跑起来：

bash复制docker run -d \
  --name postgres17 \
  -e POSTGRES_PASSWORD=mysecretpassword \
  -p 5432:5432 \
  -v pgdata:/var/lib/postgresql/data \
  postgres:17

需要注意的是，官方镜像默认数据卷挂在 /var/lib/postgresql/data，如果你想用自定义的 PostgreSQL 配置，可以把配置文件放到一个单独挂载目录，再通过 -c 参数指定。不要把宿主机目录直接挂到数据目录下，否则可能遇到权限问题。

生产环境里，如果你用的是云厂商的托管 PostgreSQL，等云厂商支持 17 之后可以直接在控制台一键升级。如果你是自己维护的物理机或虚拟机，通过 pg_upgrade 或者冷备份重放的方式升级都可以，优先推荐 pg_upgrade。

5.2 数据库同步与迁移

热搜词里频繁出现 MySQL/SQLServer/PostgreSQL 数据同步软件。这说明很多团队都在做数据库迁移或异构数据同步。PostgreSQL 生态里常用的迁移工具包括：

• pgloader：可以从 MySQL、SQLite、CSV 等迁移到 PostgreSQL，功能强大，支持类型自动转换。
• Ora2Pg：专业的 Oracle 到 PostgreSQL 迁移工具。
• Debezium + Kafka：基于逻辑复制的 CDC 方案，适合做实时数据同步。
• 云厂商自带的 DTS 服务：如果都在同一个云上，用云厂商的迁移服务是最省心的。

需要注意，任何同步工具在迁移线上数据之前，都要先做小规模数据比对。不要只看行数一致就认为数据没问题，还要对比字段级的内容，尤其留意日期时间格式、浮点精度、空字符串和 NULL 的区别。

5.3 常用客户端与 GUI 工具

很多人高频搜索 Navicat Premium 17 的许可证和注册码信息，这里必须提醒一句：请通过官方渠道购买正版授权。数据库工具是生产力工具，也是商业软件，使用盗版存在法律和安全双重风险。

除了 Navicat 之外，开源和免费的工具也不少。pgAdmin 是官方维护的图形化工具，功能完善但界面稍显笨重；DBeaver 支持多种数据库且免费；DataGrip 是 JetBrains 家的，体验流畅，适合重度开发用户。日常命令行操作的话，直接用 psql 就够了，配合 \d+、\di、\timing 这些元命令，效率其实很高。

6. 我的实际经验和后续建议

PostgreSQL 17 发布到现在，我陆陆续续在测试环境和边缘生产系统上跑了有两三个月。个人最满意的三个改进：增量备份、pg_createsubscriber、以及更加平滑的内存与 IO 表现。这三个功能不花哨，但对于真正长期运维数据库的人来说，每一项都能省去不少折腾。

如果你正在规划升级，我的建议是：从 16 到 17 属于一次值得做的升级，但不要急着一两周内完成。先做兼容性评估，找一个小流量的业务模块试运行，确认稳定后再大规模推广。

最后再分享一个小技巧。PostgreSQL 升级后，很多人会忽略 pg_stat_statements 这类扩展需要重新创建或升级。如果不处理，你会发现 pg_stat_statements 视图查不到数据，或者统计结果异常。升级后的第一件事，除了跑版本校验和 checksum 校验，把常用扩展的版本也检查一遍。我用一条 SQL 查所有扩展和它对应的默认版本：

sql复制SELECT extname, extversion FROM pg_extension ORDER BY extname;

看到结果后，逐个对比确认版本是否与 PostgreSQL 17 兼容。这一点做到位，升级后的一周你会省心很多。