Python 3.15 已于 2026 年 10 月正式发布。对大多数团队来说，这个版本没有语法层面的颠覆性变化，真正需要花时间评估的是三件事：解释器性能与 JIT 的成熟度、free-threading 无 GIL 构建现在能不能用，以及类型标注和标准库里那些“安静但影响面很广”的调整。同时，3.10 在同期进入生命周期终点，3.13 转入安全维护，升级窗口比以往更集中。本文按影响面从大到小梳理，并给出一份可执行的迁移检查清单。
一、解释器性能与 JIT：收益和负载强相关
从 3.13 开始，CPython 引入了基于 copy-and-patch 的实验性 JIT，3.14 扩大了它的可用平台，3.15 继续在分层优化上迭代。结构上可以这样理解：专门化自适应解释器（Tier 1）负责把热点字节码替换成专用指令，Tier 2 优化器把多个微操作合并成更高效的执行序列，JIT 再把结果编译成机器码。三层是叠加关系，不是互相替代。
几个实用结论：
- JIT 不改变语言语义，升级后代码行为一致，可以用
PYTHON_JIT=0/1在运行时对比，或者用sys._jit.is_available()判断当前构建是否带 JIT。 - 收益高度依赖负载。循环密集、分支密集、纯 Python 计算占比高的服务容易看到提升；IO 密集或大量时间花在 C 扩展里的程序基本感觉不到差别。
- 不要为了 JIT 去重写业务代码。先 profile，确认热点确实在 Python 层，再考虑升级解释器。
一个容易被忽略的副作用：字节码形态和内部结构在变，依赖字节码注入、sys.settrace、帧对象内部字段的调试器、覆盖率工具、APM SDK 需要同步升级，否则可能出现统计失真甚至直接崩溃。二、free-threading：从“能用”到“敢用”还有距离
无 GIL 构建（PEP 703）在 3.13 还是实验特性，3.14 起进入官方支持阶段，3.15 的目标是继续提升稳定性和扩展兼容性。需要明确的是：它仍然是一个需要显式选择的构建，并没有成为默认解释器，PEP 779 中“默认启用”的第三阶段尚未到来。
实际使用中要关注几点：
- 确认运行环境：
sys._is_gil_enabled()可以判断当前是否真的关掉了 GIL，环境变量PYTHON_GIL在支持的构建上可以切换。 - 代价是真实的：单线程性能通常低于常规构建，内存占用更高，换来的是多核并行能力。只有当程序确实是 CPU 密集且能在 Python 层并行时，收益才划算。
- 生态是关键瓶颈。C 扩展必须显式声明支持 free-threading，未适配的扩展可能无法加载；对应的 wheel 标签带
t后缀，和常规 wheel 不能混用，稳定 ABI 的支持情况也在演进，上线前请以官方文档为准。 - 以前依赖 GIL 隐式提供的原子性不再成立。列表、字典的单次操作之外的复合逻辑，以及在 C 扩展中释放 GIL 的代码路径，都需要重新审视。
三、类型标注与标准库：改动小，波及广
3.14 落地的惰性注解（PEP 649 / PEP 749）在 3.15 上已经全面生效，annotationlib 成为读取注解的标准入口。这会直接影响所有在运行时反射注解的框架：ORM、依赖注入容器、参数校验库、序列化库、CLI 参数生成器。如果代码直接读 __annotations__，可能拿到的是未求值的对象或 ForwardRef，而不是真实类型，需要改用 annotationlib.get_annotations() 或 typing.get_type_hints()。from __future__ import annotations 的作用进一步弱化，但新旧语义混用仍会带来边界问题，升级时建议统一。
标准库方面遵循“弃用至少两个版本后移除”的节奏，3.15 会清掉一批此前已发出 DeprecationWarning 的 API。最省事的排查方式是在 CI 里用 -W error::DeprecationWarning 跑一遍测试，让警告直接变成失败。另外，3.10 在 2026 年 10 月结束支持，3.13 转入安全维护，还在旧版本上的项目应该把升级排期排进本季度。
四、升级检查清单
依赖层
- 检查所有
requires-python和python_requires，特别是写死了上界（如>=3.11,<3.15）的包，需要联系上游或临时 fork。 - 重新解析锁文件：
uv pip compile --python-version 3.15或pip index versions确认每个依赖都有可用的 3.15 轮子，避免退化成源码编译。 - 关注那些依赖 C 扩展的包（数据库驱动、加密库、图像处理、HTTP 解析器），它们通常是升级的最后一块拼图。
C 扩展与 ABI
- CPython 每个小版本的 ABI 不兼容，任何自编译的扩展都必须重新编译，不能复用旧产物，也不要手工改 wheel 标签。
- 确认构建工具链版本：setuptools、cibuildwheel、Cython、pybind11、maturin 等需要支持新版本 ABI 与 free-threaded 目标。
- 使用 abi3 稳定 ABI 的包向前兼容性更好，但 free-threaded 构建的支持情况不同，需要单独验证。
- 清理 CI 缓存中的
__pycache__与编译产物，避免旧字节码和旧扩展被复用。
CI 与工程配置
- 测试矩阵增加两条腿：3.15 常规构建和 3.15 free-threaded 构建，先在非阻塞（continue-on-error）模式下观察，再决定是否设为必过。
- 更新
actions/setup-python版本、容器基础镜像标签和缓存键（务必包含 Python 版本号）。 - 同步静态检查工具的目标版本：ruff 的
target-version、mypy / pyright 的python_version、pre-commit 钩子版本。 - 在测试中添加针对线程安全和注解解析的用例，这两类问题在低版本上不会暴露。
小结
Python 3.15 更像一次“工程版本”：性能优化继续推进但收益取决于负载，free-threading 已经可评估但仍不是默认选项，类型系统和标准库的调整则会在框架层被放大。稳妥的路径是先升常规构建、跑通依赖与 C 扩展，再单独用一条 CI 分支评估无 GIL 构建，而不是一次性切换。
