Python 3.15 RC1 要不要现在试：ABI 冻结后的兼容性验证清单

Python 3.15.0rc1 已经进入候选发布阶段，适合拿来提前做兼容性预检，完全不适合直接替换线上正在用的解释器。官方明确从rc1开始就不再调整ABI相关定义，鼓励所有第三方项目提前测试、构建、发布适配3.15的wheel包；对应用开发团队来说，真正要落地的动作是把“已经兼容3.15”这个模糊结论，拆成一组可以逐条核对的工程验证记录。

结论很简单：有原生扩展、科学计算依赖或者自定义发行包的项目，现在完全可以把 Python 3.15 RC1 放进 CI 的预发布测试矩阵；生产环境还是先锁定当前在用的稳定版，等上游依赖作者完成适配、自己这边全量回归结果全部过关之后，再考虑切换的事。

RC1 的“稳定”到底稳定了什么

这次官方消息里最容易被误读成“3.15 已经完全稳定”的点，其实只是说明候选版进入了最终收尾阶段。Python Insider 公开的信息显示，3.15.0rc1 是计划推出的两个候选版本中的第一个，后续只会接纳经过严格审查、明确属于bug修复范畴的改动；从这个时间点开始，3.15 全系列不会再发生 ABI 层面的变动。

这个承诺对维护 C 扩展的项目非常友好：你现在基于 RC1 构建的 3.15 wheel，不会因为后续 rc2 或者正式版发布就出现同系列 ABI 不兼容的问题。但应用侧仍可能因为弃用逻辑变更、默认编码调整、旧构建脚本、历史测试假设或者上游依赖还没发布对应 wheel 而运行失败。不用急着修改生产镜像，先把二进制接口兼容和业务逻辑兼容这两层分开评估。

先搭一份 3.14 对 3.15 的最小验证矩阵

最省时间的做法不是直接复制整套发布流水线，而是新增一个允许执行失败的预发布任务，让它和当前在用的稳定版本共用同一份业务代码、同一组依赖锁文件和同一批核心测试用例。

strategy:
  matrix:
    python-version: ["3.14", "3.15.0-rc.1"]

steps:
  - uses: actions/checkout@v4
  - uses: actions/setup-python@v5
    with:
      python-version: ${{ matrix.python-version }}
  - run: python -m pip install -U pip
  - run: python -m pip install -r requirements.txt
  - run: python -m compileall -q src
  - run: python -m pytest -q

实际配置的时候可以按照你用的 CI 平台的预发布解释器规则调整版本字符串；核心不是逐行照搬配置，而是要保证两个版本执行完全相同的安装、编译和回归步骤。所有安装日志、安装失败的包名和测试报告都要作为构建产物留存，不然等后续上游依赖发布修复版本之后，很难定位之前的问题是不是真的解决了。

纯 Python 包跑通安装还不算完成

如果你的项目依赖 NumPy、数据库驱动、图像处理库或者自研的 Cython/C 扩展，接下来还要检查对应 wheel 是否覆盖当前要用到的平台和 Python 版本。可以先逐条记录安装环节的结果：

python -VV
python -m pip debug --verbose
python -m pip check
python -c "import your_extension; print(your_extension.__file__)"

重点核对三件事：安装过程中是否自动退回源码编译模式，导入模块时是否出现动态库加载错误，跑核心业务路径的时候是否出现新的告警或者行为和预期不符。`pip check` 只能检查已安装包的依赖声明是否匹配，没办法代替你验证扩展模块在目标机器上能不能正常工作。

几个常见的误区会让预发布验证失去意义

把 ABI 冻结直接当成业务行为冻结

ABI 解决的只是二进制接口层面的稳定性，业务代码仍可能触发弃用告警、编码逻辑差异或者第三方库的版本分支兼容问题。执行测试命令的时候要打开项目平时默认忽略的告警级别，把核心接口的输入输出做成小样本回归集，不能只看进程能不能正常启动。

只在本地开发机装一次 RC 就判定兼容

开发机能安装成功，很可能只是因为本地缓存里已经存了之前编译好的产物。至少在一个完全干净的环境里重复一次安装流程，确认最终拿到的是预期的预编译 wheel，或者明确记录下源码构建的耗时、用到的编译器版本和具体失败原因。生产镜像不能悄悄从 wheel 安装退回长时间的源码编译流程。

把预发布任务设成阻塞主分支合并的强校验

RC 阶段的目标是尽早收集整个生态的适配问题。如果每次上游依赖出小问题都导致主分支没法合并，团队很快就会关掉这条测试矩阵。更合适的策略是先允许任务执行失败，但要把失败的包名、运行平台、Python 小版本和日志链接同步给对应维护者；等核心依赖全部完成适配之后，再把核心服务的 RC 测试任务调整为必过校验。

什么时候可以把验证结果推进到灰度

可以把升级前置条件整理成一张简单的核对清单：依赖锁文件可以在任意干净环境下重复安装；所有核心原生扩展在目标平台都有可用的预编译 wheel；单元测试、接口测试和定时任务全量回归通过；启动速度、内存占用、请求延迟没有无法解释的异常波动；运行日志里没有新增高优先级告警；镜像和回滚脚本已经分别用 3.14 和 3.15 完整演练过。

哪怕这些条件全部满足，也建议先部署给内部工具、离线任务或者低流量灰度环境，不要直接替换承载核心交易业务的解释器。RC1 的价值就是给整个生态留出足够的反馈窗口，在正式版发布前发现问题，修复成本通常远低于生产切换之后再回滚。

常见问题：Python 3.15 RC1 验证到哪一步

现在要不要把团队统一的开发环境升级到 Python 3.15？

可以新增一套并行的开发环境，但不要直接覆盖团队共用的稳定环境。用独立的虚拟环境、明确分开的依赖锁文件和可以随时删除的 CI 任务把验证结果隔离开。

没有 C 扩展的项目是不是可以直接上线 RC 版本？

这类项目的兼容风险通常更低，但还是要验证依赖元数据、弃用告警、编码逻辑和部署脚本的兼容性。没有原生扩展不等于完全没有运行时兼容性问题。

rc1 环境下构建的 wheel 能不能留到最终正式版发布之后继续用？

官方公告已经说明，基于候选版本构建的 3.15 wheels 可以兼容后续所有 3.15 正式版本；正式切换前还是要按照自己的运行平台和依赖供应链，重新做一次完整的安装和回归记录。

把这条新闻变成一次可复查的版本准备工作

Python 3.15 RC1 不是“现在立刻升级”的信号，而是“现在启动验证”的信号。保留 3.14 作为稳定基线，把 3.15 接入同构 CI 流程，优先检查原生扩展适配、wheel 可用性、新增告警和回滚逻辑；每次验证失败都留下可以定位问题的完整记录。等候选版迭代、上游依赖生态适配和自身业务回归三项全部收敛之后，版本升级才是完全可控的工程动作。