Python 运行时的四个“语法正确、行为失效”位置

Python 的工程可靠性问题很少在语法层面暴露。__slots__ 写了，内存却没省下来；生成器用了，结果比列表还慢；f-string 换掉了 .format()，代码变得更难读却没有可衡量的收益；CPython 3.14 的 JIT 打开了，纯 Python 循环的加速远低于预期。这些问题的共同特征是：代码能跑，输出看起来也对，但工程意图没有兑现。下面从四个运行时位置给出可运行的验证代码与对应的工程约束。

__slots__：省的是固定开销，Broken Slots 什么也省不了

__slots__ 的经典叙事是“去掉 __dict__，每个实例省 40%–60% 内存”。这个数字在 Python 3.10 及之前大致成立，但 Python 3.11 对对象布局做了优化之后，收益明显收窄。CPython 官方 issue 中的基准数据显示：Python 3.10 每实例节省 80–216 字节，3.11 降到 40–64 字节，3.12 进一步降到 32–56 字节。属性越多，占比越低：3 个属性时节省约 38%，12 个属性时只剩 26%。

更隐蔽的问题是“Broken Slots”。如果父类定义了 __dict__，子类的 __slots__ 什么也省不了——实例仍然携带完整的字典。这种情况不会报错，只会让优化完全失效。一个可运行的验证函数应该同时检查 __slots__ 是否存在、__dict__ 是否真的消失，以及内存是否真的有差异：

import tracemalloc, gc

def slots_report(cls, n=50_000, *args):
    gc.collect()
    tracemalloc.start()
    before = tracemalloc.get_traced_memory()[0]
    objs = [cls(*args) for _ in range(n)]
    after = tracemalloc.get_traced_memory()[0]
    tracemalloc.stop()
    sample = objs[0]
    return {
        "per_instance_bytes": round((after - before) / n, 1),
        "has_dict": hasattr(sample, "__dict__"),
        "slots_effective": not hasattr(sample, "__dict__"),
    }

class Base:              # 父类有 __dict__
    pass

class Broken(Base):
    __slots__ = ("x",)   # 子类 slots 无效

class Clean:
    __slots__ = ("x",)

print(slots_report(Broken, 50_000, 1))
print(slots_report(Clean, 50_000, 1))

Broken 的 has_dict 为 True，slots_effective 为 False——它的 __slots__ 是装饰性的。工程纪律是：__slots__ 的收益必须用 tracemalloc 实测，而不是用 sys.getsizeof(obj) 单对象比较。sys.getsizeof 不含 __dict__，会得出“加 slots 反而更费内存”的错误结论。

生成器：惰性求值省内存，但不负责“更快”

生成器的核心收益是内存效率，不是执行速度。一个列表推导式一次性物化一百万个元素，生成器表达式只持有当前元素，内存差距可以达到数量级。但生成器的“晚绑定”特性会让它在闭包捕获变量时产生与直觉相反的结果：生成器表达式在迭代时才查找自由变量的值，而不是在创建时。

funcs_bad  = [lambda: i for i in range(3)]       # 晚绑定：全部返回 2
funcs_ok   = [lambda i=i: i for i in range(3)]   # 默认参数绑定当前值

print([f() for f in funcs_bad])   # [2, 2, 2]
print([f() for f in funcs_ok])    # [0, 1, 2]

生成器还有一个容易被低估的约束：只能迭代一次。如果把生成器当作“看起来像列表的东西”传给两个下游函数，第二个消费者拿到的是空序列，且不会报错。需要多次遍历时，正确的做法是传回一个可重用的工厂函数，或者显式物化为 tuple。

f-string：快是真的，但不该以可读性为代价

f-string 在 CPython 中的性能优势有明确的字节码层面的原因：它在编译期被拆解为 FORMAT_VALUE 和 BUILD_STRING 指令，避免了 .format() 的运行时方法解析和参数打包。百万次循环的基准测试中，% 格式化约 1.87 秒，str.format() 约 3.1 秒，f-string 约 0.79 秒——f-string 比 .format() 快接近 4 倍，比 % 快约 2.4 倍。

但 f-string 的工程边界不在于“该不该用”，而在于不要在需要延迟格式化的地方用。日志模块的惰性求值设计正是为了避免不必要的字符串构造：logging.debug("x=%s", x) 在日志级别高于 DEBUG 时不会格式化，而 logging.debug(f"x={x}") 会无条件执行 f-string。在高频路径上，这个差异直接决定 CPU 开销。f-string 是热路径的默认选择，但日志调用和需要结构化参数的场景是明确的例外。

3.14 的 JIT 与自由线程：加速是有条件的

CPython 3.14 引入了实验性的 JIT 和自由线程构建，但两者的收益都不是“全局加速”。在 Computerwoche 的基准测试中，一个纯 Python 数值循环在 3.14 无 JIT 下约 9 秒，开启 JIT 后只降到约 8 秒；换成自由线程构建加四线程后，同一任务降到 1.7 秒。纯循环的 JIT 收益很小，因为 JIT 优化的是类型特化和内联缓存，而不是把 Python 的逐对象运算变成 C 循环。而自由线程的 5 倍以上加速来自真正的并行，不是单线程变快了。

代价同样明确：自由线程构建在单线程工作负载上通常比 GIL 构建慢 5%–10%，某些基准上最多达到 22%。这意味着如果你的应用以单线程吞吐为主，切换到 3.14t 不是“免费提速”，而是用单线程性能换取多线程并行能力。JIT 和自由线程的正确使用方式，是在确认工作负载类型之后做针对性基准测试，而不是在 pyproject.toml 里把 Python 版本一改就期望所有代码变快。

这四个位置的共同逻辑是：Python 的运行时行为由解释器实现、对象布局和编译策略共同决定，语法只规定了“能写什么”，不保证“写了就有效”。__slots__ 要用 tracemalloc 验证 __dict__ 是否真的消失，生成器要清楚它的“一次遍历”和“晚绑定”约束，f-string 要用在热路径而不是日志惰性求值的位置，3.14 的 JIT 和自由线程要按工作负载类型决定是否启用。这些检查的成本，远低于一次“优化了但没生效”的生产排查。