Segmentation fault是PHP进程访问非法内存地址被内核强制终止，非Composer自身崩溃；需通过php -d extension=xxx.so vendor/autoload.php复现，排查C扩展兼容性、runtime-api错配或插件内存缺陷。
Segmentation fault是怎么回事
这不是 Composer 自己崩了，是 PHP 进程在执行过程中访问了非法内存地址，内核强制终止——典型表现就是终端只打印 Segmentation fault，没堆栈、没错误行号、composer install -v 也卡在某处不动。
它和 Killed（OOM Killer 杀的）完全不同，不看内存占用，得盯扩展兼容性和运行时状态。
先复现：用最小环境触发问题
别直接跑 composer install，先绕过 Composer 主逻辑，直击 autoload 阶段：
- 运行
php -d extension=xdebug.so vendor/autoload.php（把xdebug.so换成你实际启用的 C 扩展名，比如opcache.so、igbinary.so） - 如果立刻报
Segmentation fault，说明问题出在某个扩展与当前 PHP 版本或其它扩展的交互上 - 若不报错，再试
php -d zend_extension=opcache.so vendor/autoload.php（注意是zend_extension）
常见雷区：xdebug 3.3+ 在 PHP 8.1 上、igbinary 3.2.x 与 phpredis 5.3.7 组合、opcache + apcu 同时启用且配置冲突。
查 runtime-api 错配
Composer 插件（尤其是自定义插件或私有仓库工具）如果声明了不匹配的 composer-runtime-api 版本，会在 autoload 后加载插件类时触发内存越界。这类问题不会出现在日志里，但会稳定复现。
- 检查
vendor/composer/installed.json中所有插件的require字段，找"composer-runtime-api" - 运行
composer --version查当前 Composer 版本，对照官方文档确认支持的 runtime-api 范围（例如 Composer 2.5 支持^2.0，不兼容^3.0） - 临时禁用插件：删掉
vendor/bin/composer-plugin-api（如有），或重命名vendor/<plugin-vendor>/<plugin-name></plugin-name></plugin-vendor>目录再试
为什么加 --no-plugins 有时能绕过
因为插件注册阶段（PluginManager::activate()）可能调用已释放对象或未初始化的全局变量。加 --no-plugins 跳过这一步，composer install 就能走完——但这只是临时验证手段，不是解法。
真正要做的，是定位哪个插件触发了 segfault：逐个启用插件目录，配合 php -d extension=... vendor/autoload.php 测试。一旦发现某个插件单独启用就崩，基本可锁定为该插件的 Plugin 类构造函数或 activate() 方法里存在内存操作缺陷。
这类问题往往只在特定 PHP minor 版本暴露，比如 PHP 8.2.12 的 GC 行为微调后，让某个插件里未 unset 的循环引用突然触发崩溃——所以别只盯着 Composer 或扩展版本，PHP 小版本升级也可能成为导火索。
