加载失败
这次争论围绕 Python 3.14 的 CPython runtime（Python 主流 C 实现）引入 incremental GC（增量垃圾回收）后出现的生产内存压力，核心开发者因此决定在 3.14 和 3.15 回退到 3.13 的 generational GC（分代垃圾回收）。评论里有人用 memray（Python 内存分析工具）排查到 aiohttp（Python 异步 HTTP 库）客户端反复创建、SSL lib 分配回收滞后等真实案例，说明问题会直接表现成“像内存泄漏一样”的曲线。讨论也延伸到 PEP（Python Enhancement Proposal，Python 改动提案流程）、ptrace（Linux 进程跟踪接口）和运行时 profiling（剖析），因为这些 GC 和调试能力都会影响生产可观测性。更大的背景是 Python 未来是否要继续推进 JIT、free-threading/no-GIL（无 GIL 并发）等更激进的 runtime 变革，以及这会不会让 Python 失去一贯的可预测性。
不少人直接给出生产事故的例子，说明 incremental GC 不是抽象争论，而是会把内存曲线推高到像泄漏一样。有人在把服务迁到 Python 3.14 后，用 memray（Python 内存分析工具）排查出问题其实是每个请求都重建 aiohttp 客户端，叠加下游 SSL lib 的释放滞后。最终回滚到 3.13 后问题消失，所以他们只打算等 3.14.5 再试。也有人提到运行时剖析很有用，但在生产环境里常会被 ptrace 权限限制住。
很多评论质疑这类改动为什么能不经过 PEP 就进入主线，因为它虽然不改语法，却会显著改变进程的内存和 CPU 行为。有人认为问题不在于回退本身，而在于把一个有明显回归的版本先发出去，说明对核心组件的测试不够。也有人强调这是 CPython runtime 的改动，不是语言层面的变化，但正因为如此，更需要透明的提案流程来约束。还有人推测后面可能会补一个 PEP，只要性能和稳定性能达标。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
不少 Python 用户把“可预测”看得比“更快”更重要，担心 JIT 和变化中的 GC 会让 Python 变成需要频繁调参的系统。有人直接建议想要 JIT 就用 PyPy，但也指出 PyPy 的生态支持不足，而且还卡在 3.11。另一边，有人拿 Go、Java 和 .NET 对比，认为现代 GC 通过默认值和 telemetry 把不可预期的暂停压得更低；也有人反驳说 Java 现在其实已经只剩很少的 knobs。有人还提到 Jython 和 GraalVM（JVM 上的 Python 方案），但前者早已停滞，后者又受 Oracle 生态约束。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13] [来源14]
有评论把这次 GC 回退和 Meta 推动的 no-GIL / free-threading 混在一起，认为大公司一施压，Python 的问题就会被放大到全社区。随后有人澄清，这次 incremental GC 和 free-threading 是两条不同路线，后者甚至使用自己的独立 GC 设计。这个分歧也反映出大家对 Python 未来 runtime 演进的不安：一边是提升并发的诉求，一边是担心每次大改都先在生产里挨一轮。
AI 生成代码并没有让 Python 的运行特性变好，于是一些人开始用“性能”和“可读性”重新审视 Python 是否还适合作为默认选择。有人说把大规模代码迁到 Go 后，性能和维护体验都明显改善；也有人反驳，团队最终还是要对生成的代码负责，语言是否易读很大程度取决于熟悉度和习惯。围绕这一点，评论区出现了典型分歧：有人觉得 Go 的约束更利于排查复杂系统，有人则认为 Python 更直观，而且普及度更高。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10]
incremental GC: 把垃圾回收拆成更小的增量步骤执行，目标是减少单次停顿。
generational GC: 按对象“代际”分组回收，通常更偏向频繁处理年轻对象。
PEP: Python Enhancement Proposal，Python 改动和标准化的正式提案流程。
JIT: 即时编译，在运行时把代码编译成更快的机器码。
PyPy: Python 的替代解释器，主打 JIT 和不同的运行时实现。
free-threading/no-GIL: 去掉 GIL 以提升多线程并发能力的 Python 运行模式。