Python 3.13t 不是开箱即用版本，必须禁用 pymalloc、显式指定 OpenSSL 路径、设置 PYTHONNOGIL=1 环境变量，并重编所有 C 扩展；因其自由线程模式彻底改变内存管理、SSL 链接和锁机制，依赖构建与运行时环境协同适配。
python3.13t 不是装完就能跑的“开箱即用”版本，它对环境有硬性要求，本质是因为自由线程模式绕开了 GIL 之后，底层内存管理、符号链接、线程调度机制都变了——这些变化不是纯 Python 层能兜住的，必须从构建和运行时环境层面配合。
为什么编译时必须禁用 pymalloc
CPython 的默认内存分配器 pymalloc 是为单线程/带 GIL 场景设计的：它给每个线程维护独立的 freelist，靠 GIL 保证安全。一旦禁用 GIL，这些 per-thread 缓存就变成竞态源。
不加 --without-pymalloc 会导致：
• make 阶段报 undefined symbol: _PyObject_Alloc
• 或运行时报 segmentation fault，尤其在频繁创建小对象（如 int、tuple）时
• 官方明确将 pymalloc 列为 No-GIL 构建的冲突项，不是可选项，是必须关掉的
为什么 OpenSSL 路径必须显式指定
Free-threaded 构建默认不继承系统 OpenSSL 的线程安全配置，尤其是 macOS 上 Homebrew 安装的 openssl@3 默认启用多线程支持，但 CPython 的链接逻辑在无 GIL 模式下无法自动探测其线程安全 API 版本。
常见现象：
• import ssl 失败，提示 ImportError: cannot import name '_ssl'
• configure 阶段 silent skip OpenSSL，导致后续 HTTPS 请求全挂
解决方式必须是：--with-openssl=/usr/local/opt/openssl（macOS）或 --with-openssl=/usr（Linux），不能依赖 auto-detect
为什么 PYTHONNOGIL=1 必须显式设置才生效
即使你编译了 --disable-gil 版本，解释器默认仍启用 GIL——这是安全兜底策略，不是 bug。
关键点：
• sys._is_gil_enabled() 返回 True 是常态，不是异常
• 必须通过环境变量 PYTHONNOGIL=1 才真正关闭 GIL
• 这个变量只在进程启动时读取一次，运行中修改无效
• 若误设为 PYTHONNOGIL=0，哪怕构建支持，GIL 也强制开启
为什么 pyenv 和 setup-python 的行为不一致
不同工具对 3.13t 的识别逻辑差异很大：
• pyenv install 3.13t 会自动下载并启用 free-threaded 构建，且默认运行时 PYTHONNOGIL=1
• GitHub Actions 的 setup-python 中 python-version: '3.13t' 仅确保安装正确二进制，但不会自动设环境变量；必须额外加 env: { PYTHONNOGIL: '1' }
• pyenv 的 3.13t 是社区打包版，而 setup-python 的 3.13t 来自官方预编译包，两者 sysconfig.get_config_var("Py_GIL_DISABLED") 值可能不同，需单独验证
立即学习“Python免费学习笔记（深入）”；
实际环境中最容易被忽略的是：所有依赖 C 扩展的包（比如numpy、psycopg2）必须重新编译，否则即便 Python 解释器无 GIL，扩展内部仍可能因调用旧版 C API 而隐式重入全局锁，导致线程卡死或结果错乱。这不是 Python 层能控制的，必须从 wheel 构建链源头介入。 
