Python 3.13 已在 2024 年 10 月发布。升级它不应该从修改生产环境的解释器开始，而应从一份可重复的兼容性证据开始：项目能否安装、源码能否编译、测试是否通过、依赖是否提供对应 wheel，以及性能变化是否来自同一组输入。

先建立隔离基线

保留当前受支持版本，再为 3.13 创建全新的虚拟环境。不要复制旧环境的 site-packages，否则无法判断依赖究竟由哪一个解释器安装。

python3.13 -m venv .venv313
.venv313/Scripts/python -m pip install --upgrade pip
.venv313/Scripts/python -m pip install -r requirements.txt

macOS 或 Linux 的激活路径是 .venv313/bin/python。在 CI 中最好直接调用解释器完整路径，而不是依赖 shell 激活状态。

安装失败时先区分三类问题：依赖声明拒绝 3.13、平台没有预编译 wheel，或本地编译缺少工具链。不要立即加 --no-deps 强行安装；那只会把清晰的安装错误推迟成更难诊断的运行时错误。

用标准库做第一轮检查

compileall 可以在不执行应用逻辑的情况下发现语法和导入阶段之前的编译问题：

python3.13 -m compileall -q src tests
python3.13 -W error::DeprecationWarning -m pytest

把所有弃用警告直接升级为错误可能会被第三方依赖噪音淹没。实际项目可以先只检查自己的包，记录依赖警告，再逐步收紧过滤规则。随后在旧版本和 3.13 上运行完全相同的测试命令。若项目同时支持 3.12 与 3.13，CI 矩阵才是兼容性合同，开发者电脑上的一次成功不是。

下面的小脚本还能把运行环境写入测试产物，避免比较结果时忘记解释器差异：

from __future__ import annotations

import json
import platform
import sys


def runtime_fingerprint() -> dict[str, str]:
    return {
        "python": sys.version,
        "implementation": platform.python_implementation(),
        "platform": platform.platform(),
    }


if __name__ == "__main__":
    print(json.dumps(runtime_fingerprint(), indent=2))

新 REPL 是开发体验，不是部署理由

3.13 的新交互式解释器支持多行编辑、历史记录和颜色显示，异常回溯也更容易阅读。这些变化很适合探索 API 和诊断错误，但不会自动改善服务的吞吐量。CI 日志若不希望出现颜色，应使用工具自己的非彩色选项或设置合适的环境，而不是依赖终端检测碰运气。

3.13 还提供实验性的自由线程构建和实验性 JIT。两者都不应被描述为“Python 已经默认移除 GIL”或“升级即可变快”。自由线程构建是单独的运行模式，扩展模块兼容性和线程安全都需要验证；JIT 同样不是所有安装中的默认生产路径。先完成普通 3.13 迁移，再用代表性工作负载单独评估实验构建。

决定是否上线

一次可信的升级至少应留下以下证据：锁定或记录依赖版本；在所有受支持平台安装成功；新旧解释器运行同一测试集；关键任务使用相同数据做基准；回滚方式已经演练。对于包含 C 扩展的项目，还要确认 wheel 的 ABI 与平台标签，而不是只看包名版本。

Python 3.13 带来了更好的日常交互体验，也提供了值得探索的并发方向。稳妥升级的重点仍然是隔离、矩阵测试和可比较的测量。把实验特性留在独立实验中，生产迁移反而会更快、更容易解释。