直接回答：GIL 是 CPython 解释器的全局互斥锁：同一时刻只有一个线程执行 Python 字节码。它限制的是 CPU 密集的多线程并行——算圆周率开八个线程并不会更快；但 I/O 密集不受影响（线程在 I/O 时释放 GIL），C 扩展也可主动释放（NumPy 计算时多线程有效）。3.13 引入的实验性 free-threading 构建（PEP 703）编译期去掉 GIL，改用偏向引用计数、每对象锁等机制，让纯 Python 代码真正多核并行。

展开解析：现实影响分层看：现状仍是默认带 GIL，CPU 密集的标准解法是多进程（multiprocessing、进程池）或 C/Rust 扩展。free-threading 是可选构建（python3.13t），代价是单线程性能回退（官方目标压到个位数百分比）和生态适配期——C 扩展要声明支持，否则解释器回退启用 GIL。并发模型的认知升级：GIL 从不保证线程安全（list.append 原子是细节非承诺），去 GIL 后开发者要直面真实的共享可变状态竞争，threading.Lock 的使用纪律从"最好有"变成"必须有"。路线判断：Web/网络服务继续 asyncio 或多进程；数据科学、仿真计算是 free-threading 最大受益场景，但普遍成熟还需数年。

追问方向：偏向引用计数如何替代全局计数？为什么去掉 GIL 单线程会变慢？subinterpreter（PEP 734）与 free-threading 的路线关系？

（约 470 字）