Composer 本身不支持 PHP-ZTS 多线程环境，因其是单线程 CLI 工具，所有操作顺序执行、无多线程上下文；在 pthreads/parallel 中调用其 API 会因静态变量共享、非线程安全运行时状态等导致崩溃。
Composer 本身不支持 PHP-ZTS 多线程环境
Composer 是一个单线程 CLI 工具，所有操作（install、update、require）都在主线程中顺序执行，不创建额外线程，也不调用任何 pthreads 或 parallel 扩展。它不依赖 TSRM 管理资源，也不访问 Zend 的线程本地存储（TLS）。因此，无论 PHP 是 ZTS 还是 NTS 构建，Composer 都能正常运行——不是因为它“线程安全”，而是因为它根本没进入多线程上下文。
常见误解是：只要 PHP 启用了 ZTS，Composer 就能“并发安装多个包”。事实相反：composer install 默认最多并发下载 12 个包（由 COMPOSER_HTTP_MAX_PORTS 控制），但这仍是单线程调度 + 多路复用 I/O（cURL multi），不是 POSIX 线程并发。底层没有共享状态需要保护，也不存在竞态条件。
为什么不能在 pthreads/parallel 线程里调用 Composer API
如果你尝试在 Thread 或 Parallel\Runtime 中执行 Composer\Installer::run() 或手动 new Composer\Autoload\ClassLoader，会立刻触发崩溃或未定义行为。原因很直接：
- Composer 的核心类（如
Composer\Config、Composer\Repository\InstalledRepository）大量使用静态属性和全局单例（Composer\Factory::$instance） - 这些静态变量未通过 TSRM 注册，ZTS 下不会为每个线程分配独立副本，而是所有线程共用同一块内存地址
-
composer.lock解析、依赖图构建、包路径拼接等逻辑依赖getcwd()、ini_get('memory_limit')等非线程安全的 PHP 运行时状态 - 即使你绕过 autoload 初始化，
Composer\IO\NullIO等类内部仍隐式依赖STDIN/STDOUT全局流资源，在多线程下可能被不同线程同时 write 导致输出错乱或死锁
composer.lock 文件与 ZTS 完全无关
composer.lock 是纯 JSON 快照文件，不包含任何 PHP 运行时逻辑。它的生成、校验、加载过程全部发生在 CLI 主线程中，且只读解析——没有写入、没有状态变更、不触发任何扩展钩子。所以：
立即学习“PHP免费学习笔记（深入）”；
- 你在 ZTS PHP 下生成的
composer.lock，和 NTS 下生成的完全兼容，哈希一致 -
vendor/autoload.php加载时调用的Composer\Autoload\ClassLoader::register()是线程安全的：它只修改 PHP 的内部 autoloader 链表（Zend 引擎保证该链表操作原子），不读写任何共享变量 - 真正要注意的是你自己的代码：如果在
Thread中 require 了某个类，而该类的__construct()里调用了file_put_contents('log.txt', ...)，那才是竞态点——和 Composer 无关
真正要检查的线程安全边界在你自己代码里
Composer 只负责把代码放到 vendor/，它不管你怎么用。一旦你启用 parallel 或 pthreads，风险点立刻转移到你的业务逻辑：
- 避免在多个线程中同时调用
new PDO(...)并复用同一个连接对象（PDO 实例不是线程安全的） - 不要让多个线程共用同一个
Monolog\Logger实例，除非你确认它底层用了synchronized或Parallel\Channel -
$_ENV、getenv()在 ZTS 下是线程局部的，但如果你用putenv()修改，会影响整个进程——这是典型的非线程安全操作 - 第三方库若声明 “thread-safe” 通常指其 C 扩展层已注册 TSRM 资源；PHP 类库层面几乎从不承诺线程安全，需你自行加锁或隔离
最常被忽略的点：ZTS 不等于自动线程安全。它只是提供了基础设施（TSRM、Mutex），是否真安全，取决于你每一行代码是否避开共享可变状态——Composer 从不碰这个边界，但它也不会替你守住。
