Python 3.11 通过优化 .pyc 校验（引入源码哈希校验、轻量时间戳映射表、C 层实现）和减少冗余 os.stat() 调用，显著提升冷启动导入速度；但对热导入、冻结模块、禁用 pyc 等场景无效。
import 为什么会卡住？先看瓶颈在哪
你执行 import pandas 时，CPython 实际上要走一长串流程：查 sys.path → 找到 pandas/__init__.py → 检查对应 __pycache__/pandas.cpython-310.pyc 是否存在且未过期 → 读取并验证字节码 → 加载进内存 → 执行顶层代码。其中最耗时的不是磁盘读取，而是反复调用 os.stat() 检查源文件修改时间（mtime），以及每次都要解析 `.pyc` 头部做完整校验。
3.11 的 .pyc 校验改了什么
Python 3.11 默认启用 py_compile.PYC_INVALIDATION_MODE 的新策略，核心变化有两点：
-
.pyc文件头部多了 8 字节校验字段（含源码哈希 + 编译器版本），不再依赖 mtime 做唯一判断 - 解释器内部维护一张轻量级时间戳映射表，避免对同一目录下多个模块重复
stat() - 校验逻辑从 Python 层下沉到 C 层的
importlib._bootstrap_external，跳过 GIL 切换开销
这意味着：如果你的项目里有 50 个模块都从同一个包导入（比如 from mypkg import a, b, c...），3.10 会扫 50 次磁盘元数据；3.11 可能只扫 1–2 次。
哪些场景提速明显，哪些根本没用
提速不是均匀分布的，取决于你实际怎么用 import：
立即学习“Python免费学习笔记（深入）”；
- 冷启动首次导入大型包（如
torch、scikit-learn）：实测快 10%–25%，因为它们的__init__.py触发大量子模块加载和 C 扩展初始化 - 使用
zipimport或冻结模块（frozen modules）：3.11 启动更快，因重写的_frozen_importlib是纯 C 实现，函数调用更少 - 禁用了
.pyc编译（PYTHONDONTWRITEBYTECODE=1）：优势几乎归零，因为所有优化都建立在 `.pyc` 复用基础上 - 模块已存在于
sys.modules（热导入）：3.10 和 3.11 差距微乎其微，这步本来就不走校验 -
sys.path包含 NFS 或网络挂载路径：stat()优化无效，IO 仍是瓶颈，别指望提速
验证和调优时容易忽略的关键点
很多人跑 time python -c "import json" 发现没差别，是因为 json 是内置模块，走冻结路径，跟 `.pyc` 校验完全无关。真要测出效果，得盯住真实瓶颈：
- 用
python -X importtime -c "import torch" 2>&1 | head -20看最耗时的前几项，重点关注torch.__init__和torch._C加载阶段 - 确保没开
-O（优化模式），3.11 的特化机制默认只在非优化模式下激活 - 别在调试器或
sys.settrace下测，这些会强制关闭所有内联与缓存路径，结果全是“退化态” - 检查你的
__pycache__目录：3.11 生成的.pyc文件旧版本无法读取，混用环境时可能意外触发重新编译
真正影响开发体验的，往往不是单次 import 快了几十毫秒，而是那种“每次重启 Jupyter 内核都要等 4 秒”的挫败感被消除了——而这恰恰是 3.11 针对的典型冷路径。
