python 3.12 不支持多子解释器并发，因 pep 684 未实现；所有子解释器仍共享 gil，无法并行执行 python 字节码，且通信开销大、兼容性差，应优先选用 multiprocessing 或 processpoolexecutor 实现真正并发。
Python 3.12 并不支持 PEP 684 所定义的“多子解释器并发”能力——该 PEP 尚未被实现，也未合并进任何已发布版本（包括 3.12）。当前所有 Python 3.x 版本（含 3.12）仍共享全局解释器锁（GIL），且子解释器（PyInterpreterState）之间无法安全并发执行 Python 字节码。
为什么 subinterpreters 模块不能用于并发加速
Python 3.12 确实带了实验性模块 interpreters（注意不是 subinterpreters），但它只提供隔离的解释器状态，**不解除 GIL 绑定**，也不允许多解释器同时运行 Python 代码：
- 每个子解释器启动时仍独占 GIL；调用
interp.run_sync()是阻塞的，不会并行执行 - 对象不能跨解释器直接传递，必须序列化（如通过
interpreters.channel_send()），开销远超线程通信 - 标准库绝大多数模块（如
os、sys、importlib）在子解释器中行为受限或未测试，容易触发RuntimeError: cannot access interpreter state - 第三方 C 扩展几乎全部不兼容——它们通常缓存全局状态或依赖单解释器假设
实际能用的替代方案：明确场景选对工具
若目标是 CPU 密集型任务并发，应绕过解释器机制，直击本质：
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 用
multiprocessing：进程间天然隔离，规避 GIL，适合计算密集型；缺点是内存拷贝开销大、启动慢 - 用
concurrent.futures.ProcessPoolExecutor：封装更简洁，推荐作为默认选择 - 用
threading+asyncio.to_thread()（3.9+）：仅适用于调用真正释放 GIL 的阻塞 I/O 或 C 扩展（如numpy计算、requests网络请求） - 避免误用
interpreters.create()做“伪并发”——它不会提升吞吐，反而增加调试复杂度
验证你是否真在并发执行的简单方法
别只看代码里有没有 create() 或 run_sync()，用系统级观测确认：
- 运行时打开
htop或活动监视器，观察 CPU 核心占用：若只有单核跑满，说明没真正并发 - 在任务函数里加
time.sleep(0.1)后测总耗时：若 4 个任务串行执行耗时 ~0.4s，而你期望并行却仍是 ~0.4s，就证明没并发 - 检查是否出现
RuntimeError: interpreter is not running或ChannelClosedError——这些是跨解释器通信失败的典型信号，意味着你正在踩 PEP 684 尚未落地的坑
PEP 684 的愿景是让子解释器摆脱 GIL 束缚，但截至 Python 3.12，它仍停留在 PEP 文档和 CPython 开发者讨论中。现在写代码，得按“单 GIL + 进程隔离”这个现实模型来设计，而不是按未来规范去猜接口行为。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
