Python 3.11性能提升默认启用但非万能，需代码满足热点执行、类型稳定、字面量访问等条件才生效；否则如IO密集、短命进程或动态访问场景下提速不明显。
Python 3.11 的性能提升不是靠“开启某个开关”或“加个装饰器”实现的——它默认启用、无法关闭，但是否真能提速，取决于你的代码是否满足特化解释器的运行条件。
为什么升级到 3.11 后没感觉变快？
常见现象：换上 Python 3.11，跑同一段脚本，time 命令测出来耗时几乎没变。原因通常是：
- 代码未进入热点路径：比如只执行一次的 CLI 工具、短命进程（如 AWS Lambda 单次调用）、或主要开销在
requests.get()/open().read()这类 IO 上 - 类型不稳定：例如
obj.field有时返回str，有时是None或int，导致LOAD_ATTR无法特化为LOAD_ATTR_INSTANCE_VERBOSITY - 用了动态访问模式：
getattr(obj, field_name)、obj.__dict__[key]或未定义__slots__的类频繁增删属性，都会让内联缓存失效 - REPL 或模块 reload 后直接
dis.dis(func)：没加adaptive=True参数，也未先调用函数 ≥3 次，看不到特化效果
如何验证特化解释器是否生效？
别猜，用官方工具看真实行为：
- 加参数运行：执行
python3.11 -X showspeculation your_script.py，终端会逐行打印哪些字节码被特化、命中多少次 - 对比指令变化：先调用目标函数至少 5 次（触发特化），再运行
dis.dis(func, adaptive=True)，能看到CALL_FUNCTION变成CALL_FUNCTION_EX、LOAD_ATTR变成LOAD_ATTR_INSTANCE_VERBOSITY等 - 排除干扰：测试时加
setarch $(uname -m) -R python关闭 ASLR，避免pyperf测量抖动
哪些写法能让特化真正起效？
特化不是玄学，它对代码结构敏感。以下写法能显著提升命中率：
立即学习“Python免费学习笔记（深入）”；
- 用
obj.field_name替代getattr(obj, 'field_name')，字段名必须字面量、不可变 - 给高频访问的类加上
__slots__ = ('x', 'y', 'name')，固定对象内存布局 - 避免在循环中混用不同类型：比如
for x in data:中x始终是int，不要有时是float或None - 减少 try/except 范围：把
try: result = obj.method()单独拎出来，比包着日志、序列化等重操作更利于零成本异常机制生效
多进程/多线程部署时要注意什么？
特化状态不跨进程、不跨线程共享：
- Uvicorn 的
--workers 4模式下，每个 worker 进程要各自“热身”，预热脚本需对每个 worker 单独发请求 - Gunicorn prefork 模式中，fork 出的子进程可继承父进程已积累的部分特化缓存，但
os.exec或全新启动（如容器重启）则完全从零开始 - 不要指望写一个“全局预热函数”让所有线程受益——每个
PyInterpreterState都有自己的adaptive_state
最容易被忽略的一点：特化不是配置项，也不是编译期优化；它是解释器在进程生命周期内，靠真实执行历史“学出来”的行为。冷启动快、短命任务多、类型总在变——这些场景下，3.11 的加速优势天然受限。
