Python 3.15.1小版本升级前怎样安排兼容检查

Python 3.15.1 升级前，先确认升级起点，再用独立环境重建依赖，分别检查包的依赖关系、应用核心功能和部署回退条件。如果原来使用 3.15.0，重点是维护版本的修复影响；如果来自 3.14 或更早版本，还要处理整个 3.15 系列的迁移变化。把这两类升级混在一起，会漏掉真正需要回归的范围。

Python 官方发布页将 3.15.1 标为 2026 年 10 月 21 日发布的首个 3.15 维护版本和加急安全发布，并已提示它被 3.15.2 取代。因此，本文以团队需要复核 3.15.1 候选环境为例说明检查安排，不把它当作当前最新版本，也不建议仅因为本文示例而固定生产目标。

官方地址：https://www.python.org/

先确定升级起点与目标版本

在任务单里同时写出旧解释器、目标解释器、操作系统、CPU 架构和构建类型。只写“升级 Python 3.15”，不足以让另一个人复现相同环境。尤其不要在更换维护版本时顺便切换普通构建与自由线程构建：两个变化叠加后，依赖行为差异更难归因。

一个实用的安排是先固定应用代码和依赖版本，只比较解释器变化。如果候选环境无法安装某个锁定依赖，再单独处理那项依赖，而不是一开始就把所有包升级到最新。这样留下的失败记录更容易定位。

用独立环境固定解释器与依赖

下面给出 Unix/macOS 风格的最小示例。前提是已经单独安装目标解释器，并准备好项目维护的 requirements.lock。示例中的文件名是团队约定，不是 Python 自动生成的文件；它应包含本项目可重建的依赖约束。命令仅供读者使用，本文没有在本机安装解释器或执行测试。

# 将变量改成目标安装中 Python 可执行文件的完整路径，避免混用系统解释器
TARGET_PYTHON=/opt/python3151/bin/python3.15

# 首先展示目标版本；确认是预期的3.15.1后再继续
"$TARGET_PYTHON" --version

# 创建新的候选环境，保留旧环境作为比较基线
"$TARGET_PYTHON" -m venv .venv-candidate

# 始终使用候选环境自己的pip，依照项目锁定依赖安装
.venv-candidate/bin/python -m pip install -r requirements.lock
.venv-candidate/bin/python -m pip check

Windows 上应使用目标安装的解释器创建环境，并把环境内的可执行文件路径换为 .venv-candidate\Scripts\python.exe。这里没有要求激活环境，因为显式调用环境中的解释器更容易看清每条命令究竟作用于哪个环境。

venv 建立在一个已有 Python 安装之上，默认隔离基础环境中的包。它不是可以任意复制的部署目录；跨机器或切换基础解释器时，应依据依赖记录重建。也不要直接覆盖旧虚拟环境，随后把“还能运行”当成新环境已独立准备好的证据。

把依赖可安装与业务可用分开

pip check 检查已安装包的依赖关系是否兼容，例如缺少依赖或版本约束不满足。它不会替你调用支付接口、检查导出文件内容，也不会证明原生扩展的全部功能正常。安装成功与依赖检查通过，是继续做功能回归的条件，不能替代应用测试。

如果项目使用标准库 unittest，可以在两套环境中分别运行同一套用例。下面假定项目的测试文件位于 tests，符合 test_*.py 命名约定；使用其他测试框架的项目应保留已有入口。

# 在候选解释器下发现并运行项目现有测试；-v保留具体用例名
.venv-candidate/bin/python -m unittest discover -s tests -p 'test_*.py' -v

# 将弃用警告显示出来，便于区分既有问题和本次版本变化
.venv-candidate/bin/python -W default -m unittest discover -s tests -p 'test_*.py' -v

第二条是需要观察警告时的另一次运行方式，并非必须重复跑两遍。还要核对测试发现的数量；零用例正常退出，不代表功能已经覆盖。对只在特定任务中加载的模块，应让对应路径真正被调用，不能仅凭应用主模块导入成功下结论。

例如，一个订单导出服务可以分别检查：空订单导出是否保留表头、中文客户名是否按约定编码、日期边界是否正确、外部服务超时是否按原规则返回错误。这些是示例检查方向，应换成自己项目的真实输入与预期；不要为凑清单添加与应用无关的测试。

针对版本差异处理兼容分支

如果升级起点是 3.15.0，不应把 3.15 相对 3.14 的所有新特性都称为 3.15.1 引入。维护升级中发现异常时，先找对应修复记录和依赖变动，再决定是否需要改代码。保留原先通过的行为断言，比为了适配而直接放宽所有断言更有帮助。

若从较早次版本迁移，则需要额外阅读 3.15 的迁移章节。例如，官方说明 3.15 默认使用 UTF-8 编码。项目如果依赖系统默认编码，应检查文件交换协议究竟规定什么编码，再显式声明；不能为了消除报错就统一改成忽略解码错误，否则可能把数据丢失藏起来。

对于原生扩展，应记录候选环境实际安装的是哪个构件，以及是否触发源码构建。导入阶段的问题与调用特定函数时的问题要分开记录。没有适配构件时，先查维护方支持范围与构建要求，再决定等待适配、受控构建或调整依赖；不要仅靠跳过安装错误继续发布。

回退兼容也要有范围：如果应用仍承诺支持旧解释器，就在旧环境保留相同测试。此次任务只调整解释器，通常没有必要同时引入新语法、重写导入方式或改动并发模型。将这些改造拆成后续任务，能减少一次升级中同时变化的因素。

性能对照与回退一起安排

性能比较至少固定应用提交、依赖记录、输入规模、机器资源和预热方式。先确认业务结果相同，再比较启动耗时、任务耗时和资源占用。单次运行的快慢容易受机器负载影响，不应把官方对某个构建的性能说明直接换算成自己应用的收益。

回退时需要恢复的是能够协同工作的解释器、应用构件和依赖组合。保留旧安装或旧部署镜像，并确认部署入口指向哪套环境。如果业务发布还改动了数据库结构或外部消息格式，解释器回退并不会自动还原这些变化，应为它们另设兼容或恢复方案。

3.15.1 还能作为兼容复核目标吗？

可以用于复现历史部署或核对既定变更，但选择新的生产目标时应重新查看官方维护版本与安全说明，不能把本文中的目标版本当作长期推荐。

只升级解释器，还需要重新检查 pip 吗？

需要区分解释器安装附带的工具和已有虚拟环境中的工具。3.15.1 发布说明对既有环境的 pip、uv 更新另有提示；不要假定安装新解释器会自动更新所有旧环境。具体处理应遵循官方安全说明。

依赖检查通过但业务测试失败，该先改哪里？

先保留失败输入与旧环境结果，确认差异来自解释器、依赖还是测试环境。依赖关系满足只说明包的声明约束没有冲突，不能决定业务代码该如何修改。

官方资料：https://www.python.org/downloads/release/python-3151/；https://docs.python.org/3.15/whatsnew/3.15.html；https://docs.python.org/3.15/library/venv.html；https://pip.pypa.io/en/stable/cli/pip_check/；https://docs.python.org/3.15/library/unittest.html。