先看证据
两个版本节点，指向两种不同的决定
Python 项目于 2026 年 10 月 9 日发布了 3.15.0 稳定版。它带来显式惰性导入、推导式中的解包，以及新的采样分析器；这些变化分别触及启动开销、代码表达和性能诊断。Simon Willison 在介绍新版本时，也宣布自己的开源项目将告别 Python 3.10，并开始使用 3.11 的功能。
这两个动作挨得很近，却不是一回事。Python 3.10 于 10 月 1 日结束生命周期，维护者是否停止支持它，取决于项目自己的兼容政策；3.15 的发布并没有要求所有项目升级。对负责人来说，关键问题不是“要不要追最新版”，而是最低支持版本是否该随支持周期调整，以及调整后能否换来实际的维护收益。
把启动成本推迟，而不是凭空消除
Willison 的例子来自一个支持插件的 LLM 命令行工具：插件如果依赖 `sentence_transformers` 这类重型库，即使一次命令没有用到相关功能，导入也可能让每次启动多耗数秒。过去他只能在插件作者文档里建议手动延迟导入。Python 3.15 的 PEP 810 则允许写成 `lazy import json` 或 `lazy from pathlib import Path`，把“何时加载”明确交给代码表达。
被标记的模块会先以轻量代理形式出现，等后续代码第一次使用相应名称时才真正加载。这样一来，不会走到的插件路径就不必承担启动时的导入成本；代价是成本并未消失，而是移到了首次调用处。模块加载失败的异常也会延后到首次访问时才出现，而且 `lazy` 只能用于模块作用域，因此它改变的不只是速度，也改变了错误暴露的时机和测试重点。
诊断能力进了标准库，性能承诺仍要克制
3.15 还把采样分析带进了标准库。采样分析器 Tachyon 会周期性抓取运行中进程的调用栈，再据此估算哪些函数占用了更多时间；与需要先埋点的方式不同，它可以附加到已有的 Python 3.15 进程。Willison 给出的操作入口是 `python -m profiling.sampling attach <PID>`，停止采集后可查看报告，也能生成火焰图、热图，或输出供 Firefox Profiler 查看的数据。
这对运维和性能排查的价值，是降低“先改代码才能观察”的门槛，而不是自动给出根因。Tachyon 适合帮助团队找到值得继续调查的热点，但采样结果仍需要结合工作负载解释。性能数字也不支持把 3.15 宣传成普遍提速：针对 3.15.0rc3 的测试显示，它整体与 3.14 大致相同；实验性 JIT 在斐波那契测试中比标准解释器快 1.2 倍，这只是特定测试和实验实现的结果。
抬高兼容底线，换取的是什么
告别 3.10 后，Willison 可以把项目最低版本设为 3.11，并直接使用这一版本加入的标准库能力。例如，`tomllib` 可解析 TOML，`asyncio.TaskGroup` 和 `asyncio.timeout()` 提供异步任务组与超时控制，`datetime.UTC` 则是 UTC 时区的便捷名称。SQLite 接口也增加了 `setlimit()`、`getlimit()`、`create_window_function()` 和 `blobopen()` 等能力。对维护者而言，这些功能可能减少额外依赖或自维护代码，但前提是项目用户也能接受最低版本提高。
这也解释了为什么“本机用 3.15”和“项目最低支持 3.11”可以同时成立。Willison 用 `uv` 将全局默认版本设为 3.15，项目若固定了其他版本，仍优先遵循项目设置；他还把若干项目模板的测试范围设为 3.11 至 3.15。全局默认值服务于日常开发，项目底线定义的是兼容承诺，两者不应混为一谈。提高底线会放弃仍依赖 3.10 的用户，因此需要先核对用户需求、依赖兼容性和测试矩阵，而不是仅凭新版本发布就统一升级。
升级判断应落在具体工作负载上
Python 3.15 最实在的变化，是给维护者多了几种可以纳入工程设计的选择：按需导入插件依赖、从运行中的进程采样诊断，并在支持周期结束后重新评估兼容底线。推导式解包则属于更局部的表达能力改进，它能让部分嵌套推导式和 `itertools.chain()` 风格的展开写法更直接，但本身不足以构成迁移理由。
如果团队的主要痛点是 CLI 冷启动，可以先检查哪些模块在常见命令路径中并未实际使用，再评估惰性导入，并为延迟出现的导入错误补上测试。如果问题是线上性能未知，采样分析器提供了标准库入口，但仍要围绕真实负载解读数据。至于是否提高最低版本，则应把支持周期、用户分布和维护成本放在一起判断；3.15 给出的不是一个统一答案，而是更清楚的取舍工具。