无GIL模式需专用解释器且无法动态启用：必须用python3.13t或--disable-gil编译版，运行sys._is_gil_enabled()返回False才生效；内置类型改用对象级锁，跨操作仍需手动同步；C扩展如pandas基本不可用，numpy≥1.27.0部分支持；单线程性能反降5%–15%，多线程提速有限，stdout写入易乱序。
不能直接“开启”无GIL模式，必须用专门编译的解释器运行，且多数常见库（如pandas、旧版numpy）会崩溃或返回错误结果。
怎么确认你真在跑无GIL解释器
很多人装完就以为生效了，结果调用的还是带GIL的python3.13。关键看两点：
- 必须显式使用
python3.13t（Windows/macOS官方安装包）或你自己用./configure --disable-gil编译出的二进制 - 运行时验证：
python3.13t -c "import sys; print(sys._is_gil_enabled())"输出False才算成功；若报AttributeError，说明你根本没跑对解释器 -
PYTHONNOGIL=1 python3.13 -c ""这类环境变量方式无效——它不能给一个原本带GIL的解释器“动态关锁”
threading.Thread并行了，但dict/list不再天然安全
无GIL ≠ 所有内置类型自动线程安全。CPython 3.13 改为 per-object 锁：每个dict、list实例有自己的轻量锁，但跨对象操作仍需手动同步。
-
d[k] = v这类单键写入通常没问题，底层已加锁 -
for k in d: d[k] *= 2会触发RuntimeError: dictionary changed size during iteration，因为迭代器和修改不再被全局锁串行化 - 共享计数器（如
counter += 1）必须用threading.Lock或_thread._atomic，不能再靠GIL隐式保护
C扩展兼容性差，pandas/numpy目前基本不可用
大量C扩展在无GIL下会段错误或返回错误结果，根源是它们的C代码假设GIL存在，未对引用计数、全局状态做原子保护。
python-docx
下载
python-docx Skill功能概述python-docx Skill是一项面向实际任务的技能，主要用于本Skill提供使用python-docx生成专业Word文档的标准方法和最佳实践；生成安全服务方案文档；核心要点生成技术架构设计文档；生成任何需要专业排版的Word文档；核心库 : python-docx；使用与执行辅助库 : docx.shared , docx.enum , docx.oxml.ns；标准代码模板；1. 文档初始化；2. 字体设置（必须！它将相关步骤、工具调用和结果整理方式集
立即学习“Python免费学习笔记（深入）”；
-
pandas导入即失败，尚未发布稳定兼容版本 -
numpy≥1.27.0 声称支持，但实测部分ufunc和广播操作仍有数据竞争 -
requests、httpx、json等纯Python库基本可用 - 调试工具如
py-spy必须≥0.9.4才能正确抓取NOGIL栈帧
单线程性能反而下降5%–15%，别急着替换线上服务
无GIL解释器为保障线程安全，在对象分配、引用计数、GC标记等路径上引入原子指令和内存屏障，导致单线程吞吐下降。实测中，纯Python CPU密集任务在4线程下可能提速2–3倍，但同一代码在单线程下跑得更慢。
真正容易被忽略的是：stdout写入本身在多线程下可能因缓冲区争用而乱序或卡死——别依赖print()调试，改用logging配合threading.Lock更稳妥。
