Python 3.15.2 等五个补丁版同时发布：升级节奏该怎么跟

10 月 26 日，Python 3.15.2、3.14.10、3.13.18、3.12.16、3.11.18 五个补丁版本同时发布。3.15 主版本是 10 月 9 日刚出的正式版，半个月就打到 .2，这个节奏说明首批问题反馈得比较集中。

补丁版该不该跟

该跟，但要分清两类。纯 bug 修复的补丁版，升级风险低，收益是修掉那些「偶发但很烦」的问题。带安全修复的补丁版，必须跟。判断方法很简单：看发布说明里有没有 CVE 编号。

几个实践建议

不要在程序里钉死补丁号。用 3.15 这样的主次版本别名，让构建时自动拿最新的补丁版，安全更新才不会漏。托管平台通常也是这个策略，Heroku 这次就同时更新了 3.15、3.14、3.13、3.12、3.11 的别名指向。

CI 矩阵里至少保留两条线：主用版本和下一个要迁的版本。只在一条线上跑测试，等真要升级时会发现积了一堆兼容问题。

对库作者，补丁版发布后尽快构建 wheel 并上传，下游才有条件测试。这件事经常被忽略，结果是「官方修了但生态装不上」。

3.15 的两个提醒

默认编码改成 UTF-8 之后，任何依赖平台默认编码读写文件的代码行为都会变，尤其是处理 GBK 历史数据的老脚本，升级前先跑一遍。惰性导入虽然好用，但只在模块作用域允许，写在函数里不行，迁移时注意改写位置。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

别在程序里钉死补丁号，用主次版本别名让构建时自动拿最新补丁版，安全更新才不会漏。CI 至少保留两条线，只在一条线上跑测试，真要升级时问题会积一堆。

钉死补丁号这事我站反方。我们线上一直锁到补丁位，理由不是怕升级，是怕不可复现：客户现场报的问题，三个月后要复现，容器里必须还是那个版本。折中办法是每季度集中升一次，灰度跑两周，带 CVE 的单走紧急通道，别和常规补丁混在一条流水线上。

我们的做法是把补丁号放进镜像 tag，CI 只钉到次要版本，升级走每周一次的自动 PR，测试过了才合。踩过的坑是某个补丁版悄悄改了一处默认行为，用例没覆盖，上线才发现。你们是每个补丁都跟，还是攒一批一起上？