TSRM是PHP内核中实现线程安全的资源隔离机制，编译时通过--enable-maintainer-zts启用、--disable-zts禁用；多线程SAPI（如worker/event MPM）必须启用，而prefork、PHP-FPM、CLI等应禁用以提升性能与稳定性。
TSRM 是什么，为什么 PHP 编译时要选它
TSRM（Thread Safe Resource Manager）是 PHP 内核中用于支持多线程环境的资源隔离机制。它不是“可选功能”，而是编译时决定是否启用线程安全支持的关键开关。你**不会在运行时切换 TSRM 策略**，而是在 configure 阶段通过 --enable-maintainer-zts 或 --disable-zts 控制是否启用 TSRM。
关键判断：如果你用的是 Apache 的 worker MPM、event MPM，或嵌入到多线程 C/C++ 服务中（如某些 SAPI），就必须启用 TSRM；如果用的是 prefork MPM、PHP-FPM、CLI 或 Nginx + FastCGI，则**禁用 TSRM（即不加 --enable-maintainer-zts）更高效、更稳定**。
configure 时怎么正确启用/禁用 TSRM
PHP 源码编译时，默认不启用 TSRM（即 --disable-zts）。只有显式加上 --enable-maintainer-zts 才会启用它，并自动定义 ZTS 宏、链接 libtsrm、使用线程局部存储（TLS）管理 ts_resource。
- 启用 TSRM（仅限多线程 SAPI 场景）：
./configure --enable-maintainer-zts --with-apxs2=/usr/bin/apxs
- 禁用 TSRM（推荐绝大多数场景，包括 PHP-FPM）：
./configure --disable-zts --enable-fpm
- 误加
--enable-maintainer-zts却跑在 prefork 或 FPM 下，会导致额外 TLS 开销、部分扩展（如某些未适配 ZTS 的 PECL 扩展）加载失败，错误类似：PHP Warning: Module 'xxx' already loaded in Unknown on line 0或直接 segfault
如何验证当前 PHP 是否启用了 TSRM
不要只看 phpinfo() 页面里有没有 “Thread Safety” 字样——有些旧版或自定义构建可能漏写。最可靠的方式是检查二进制本身的符号和宏定义：
立即学习“PHP免费学习笔记（深入）”；
- 运行
php -i | grep "Thread Safety"，输出enabled表示启用了 TSRM；disabled表示未启用 - 检查编译参数：
php -r "echo PHP_CONFIG_FILE_PATH;"不适用，应改用php -r "echo defined('ZTS') ? 'ZTS enabled' : 'ZTS disabled';" - 底层验证：执行
objdump -t $(which php) | grep tsrm，若看到tsrm_ls、ts_resource_ex等符号，基本确认启用了 TSRM
扩展开发时绕不开的 TSRM 宏与陷阱
写 ZTS 兼容扩展时，所有全局变量（尤其是 static 变量）必须用 TSRMLS_* 宏包裹，否则在多线程下会数据错乱。PHP 7.4+ 已移除这些宏，改用隐式全局访问（PG()、EG() 等已内置线程安全），但 PHP 8.0+ 的扩展仍需注意内核版本兼容性。
常见坑点：
- PHP 7.2–7.4 扩展中漏写
TSRMLS_DC参数导致编译失败，错误如：too few arguments to function 'php_myext_init' - 在非 ZTS 构建中调用
ts_resource_ex会链接失败，因为该函数只在libtsrm中定义 - 调试时发现
zend_executor_globals地址在不同请求间变化？那是 TSRM 正常行为——每个线程持有一份独立副本
真正在意性能或稳定性，就别强行“统一开启 TSRM”。它不是银弹，而是为特定部署模型服务的底层设施。多数 Web 场景用 prefork/FPM，关掉它反而更干净。
