C扩展在python3.13t中直接段错误，因其C代码隐式依赖GIL：Py_INCREF/DECREF无原子保护、全局状态访问未加锁，移除GIL后引发引用计数竞态、野指针访问或内存越界。
为什么C扩展在python3.13t里直接段错误？
因为绝大多数C扩展（比如numpy、pandas、psycopg2）的C代码隐式依赖GIL存在：它们调用Py_INCREF/Py_DECREF时不加原子保护，假设引用计数操作会被GIL串行化；修改全局状态（如_PyRuntime字段、线程本地字典）时也不上锁。无GIL下这些操作变成竞态点，轻则数据错乱，重则内存越界触发Segmentation fault。
哪些C API调用在无GIL下会崩？
以下模式在python3.13t中高危，常见于未适配的扩展：
-
Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS成对缺失或嵌套错位——原意是“临时放GIL”，现在变成“彻底放飞”，后续访问Python对象可能无锁竞争 - 直接读写
PyInterpreterState结构体字段（如interp->modules），该结构在无GIL构建中已改为线程局部副本，跨线程访问即野指针 - 在C函数里调用
PyGILState_Ensure()后不做PyGILState_Release()，导致TLS状态泄漏，后续线程初始化失败 - 用
PyObject_Call()间接触发Python层回调，而回调函数内部又操作共享dict/list——此时per-object锁不覆盖跨对象调用链
pip install numpy为什么会失败或装完就import报错？
根本原因不是安装阶段出错，而是运行时ABI断裂：
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 二进制轮子（
numpy-1.26.4-cp313-cp313-win_amd64.whl）由带GIL的CI环境编译，链接了libpython313.dll中带GIL语义的符号（如PyThreadState_Get返回值被当成全局有效） - 无GIL解释器中，
PyThreadState已按线程隔离，同一地址在不同OS线程里指向不同内存页，C扩展拿这个指针去查模块表，必然读到垃圾数据 - 即使强行绕过pip校验（如
--force-reinstall），import时numpy.core._multiarray_umath初始化阶段就会因引用计数溢出或GC上下文错乱而abort
怎样快速判断一个C扩展是否支持无GIL？
别信文档，直接跑验证脚本：
立即学习“Python免费学习笔记（深入）”；
python3.13t -c "
import _testcapi
try:
_testcapi.test_thread_state_api()
print('thread state API safe')
except RuntimeError as e:
print('unsafe:', e)
"
若输出unsafe: thread state not isolated，说明该扩展仍把PyThreadState当全局句柄用。更严苛的检测要检查它是否声明了PyModuleDef.m_slots中含Py_mod_exec且实现里调用了PyImport_AddModuleObject——这类操作在无GIL下已被标记为DEPRECATED。
psycopg2连接池在无GIL下可能返回已关闭的连接对象，错误只在SQL执行时暴露，调试成本远高于直接拒绝加载。 
