python 3.13无gil模式使threading.thread在cpu密集型场景真正并行，但需显式使用python3.13t并验证sys._is_gil_enabled()为false，且dict/list改用per-object锁、c扩展兼容性差、单线程性能下降5%–15%。
python3.13t 让 threading.Thread 在 CPU 密集型场景真正并行，但不是“所有多线程都变快了”——它只解决 GIL 原本锁死的那部分瓶颈，且代价明确、限制具体。
怎么确认你真在跑 NOGIL 解释器？
很多人装完就开跑，结果threading.Thread 还是串行，因为根本没进自由线程模式。
必须同时满足两个条件：
- 启动的是专用二进制，不是标准 python3.13：Windows/macOS 官方安装包提供 python3.13t；Linux 用户需从源码用 ./configure --disable-gil 编译
- 运行时验证状态：python3.13t -c "import sys; print(sys._is_gil_enabled())" 输出 False 才算生效
- PYTHONNOGIL=1 python3.13 -c "..." 无效：环境变量不能给带 GIL 的解释器“动态去锁”，它只对编译时已启用 NOGIL 的二进制起作用
为什么 dict/list 并发写入不报错，但遍历+修改会崩溃？
NOGIL 下不再有全局锁兜底，CPython 改用 per-object 锁：每个dict、list 实例自带轻量互斥锁。
这意味着：
- d["a"] = 1 和 d["b"] = 2 在不同线程并发执行通常安全，底层已加锁
- 但 for k in d: d[k] *= 2 会触发 RuntimeError: dictionary changed size during iteration，因为迭代器和修改操作不再被同一把锁串行化
- 跨对象操作（如线程 A 往 dict_a 写、线程 B 往 dict_b 写、线程 C 合并二者）仍需手动加 threading.Lock第三方 C 扩展为啥一用就段错误？
pandas 导入即失败、numpy 某些 ufunc 返回乱数据、cv2 直接 segfault——这不是 bug，是设计预期。 根源在于：这些 C 扩展的代码假设 GIL 存在，未对以下内容做原子保护： - 引用计数增减（仍用Py_INCREF 而非 Py_ATOMIC_INCREF）
- 全局静态变量（如 OpenCV 内部缓存、pandas 的类型注册表）
- C 层共享缓冲区（如 numpy 数组的 data ptr 被多个线程裸读写）
目前仅少数库明确支持：
- numpy >= 1.27.0 声称兼容，但 np.einsum、广播赋值等路径仍有竞争
- py-spy >= 0.9.4 才能正确抓取 NOGIL 栈帧
- 纯 Python 库（requests、httpx、json）基本无风险
单线程反而更慢，这是正常现象
别指望 NOGIL 是“免费升级”。为保障细粒度并发安全，解释器在以下路径引入开销： - 对象分配、引用计数、GC 标记全部改用原子指令（atomic_load、atomic_store）
- 每个内置类型实例维护独立锁结构，增加内存占用和 cache miss
- 默认启用 mimalloc 分配器，首次分配延迟略高
实测单线程性能平均下降 5%–15%，尤其在高频创建小对象（如列表推导、字典解析）的场景。
如果你的服务 90% 请求是单线程逻辑，只在少数后台任务用多线程计算，盲目切换 python3.13t 可能得不偿失。
真正的多核并行能力来了，但线程安全责任也同步前移——你不能再依赖 GIL 隐式保底，每一处共享状态访问，都得自己想清楚锁在哪、锁什么、锁多久。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
