根本原因是PHP CLI环境未启用pcntl扩展，而symfony/console v6.2+等第三方包在初始化时调用pcntl_signal触发警告并被Composer错误处理器捕获为致命错误；需检查php -m | grep pcntl，未启用则通过对应方式开启，或临时设SF_SKIP_SIGNAL_HANDLER=1绕过。
Composer 运行时抛出 pcntl_signal 被禁用的错误，根本原因不是 Composer 本身依赖该函数，而是你当前 PHP 环境禁用了 pcntl 扩展（或未启用），而某些第三方包（如 symfony/console v6.2+、laravel/pint、spatie/phpunit-snapshot-assertions 等）在信号处理逻辑中尝试调用 pcntl_signal，触发了 PHP 的 E_WARNING 并被 Composer 的错误处理器捕获为致命错误。
为什么 composer install/update 会触发 pcntl\_signal 错误
这不是 Composer 主流程的问题，而是它加载的依赖包在初始化或命令行交互阶段做了信号注册。典型场景包括：
- 使用
symfony/console≥6.2 的命令行应用（如 Laravel 10+ 的artisan或自定义命令）在composer install后首次运行时触发 - 某些插件（如
hirak/prestissimo已弃用，但类似加速器）尝试监听SIGINT实现中断恢复 - CI 环境（如 GitHub Actions）默认 PHP 不启用
pcntl，且未显式禁用信号处理逻辑
关键点：pcntl_signal 是扩展函数，PHP CLI 模式下需手动启用，Web SAPI（如 Apache/FPM）默认禁用且不可用 —— 但 Composer 只跑在 CLI 下，所以问题只出现在 CLI 配置缺失时。
检查并启用 pcntl 扩展（Linux/macOS）
先确认是否真的没启用：
php -m | grep pcntl
如果无输出，说明未启用。启用方式取决于你的 PHP 安装方式：
- 源码编译：重新 configure 时加
--enable-pcntl - Ubuntu/Debian：安装
php-cli包通常自带，否则运行sudo apt install php-cli - macOS + Homebrew：运行
brew install php后，pcntl默认启用；若用旧版，检查php.ini中是否有extension=pcntl - Docker：在
Dockerfile中添加RUN docker-php-ext-enable pcntl（前提是已编译）
验证是否生效：
php -r "var_dump(function_exists('pcntl_signal'));"
应输出 bool(true)。
临时绕过信号注册（不推荐长期使用）
如果你无法启用 pcntl（如共享主机、受限 CI 环境），可在 Composer 命令前屏蔽相关警告，并确保依赖不实际调用它：
- 设置环境变量禁用 Symfony 的信号处理：
SF_SKIP_SIGNAL_HANDLER=1 composer install - 降级触发问题的包版本，例如将
symfony/console锁定在"^5.4 || ^6.0"（避开 6.2 引入的默认信号注册） - 在
composer.json的config中添加："platform": {"ext-pcntl": "7.4.0"}—— 这不会启用扩展，但可欺骗某些包跳过运行时检测（仅对做extension_loaded('pcntl')检查的包有效）
注意：platform 配置不能解决真正调用 pcntl_signal() 的情况，只是让 Composer 安装阶段不报错；运行时仍可能 crash。
常见错误信息与对应位置
你看到的错误通常长这样：
PHP Warning: pcntl_signal(): pcntl extension is not available in /vendor/symfony/console/Application.php on line 1023
或：
Call to undefined function pcntl_signal()
这类报错一定指向某个 vendor 包里的代码，而非 Composer 自身。搜索关键词：pcntl_signal、SIGINT、declare(ticks=1)。最常出问题的是：
-
symfony/consolev6.2+ 的Application::doRun() -
reactphp/event-loop的某些适配器 - 自定义的 long-running CLI 脚本被当成 Composer 插件加载
真正麻烦的不是 Composer 报错本身，而是它掩盖了底层包对信号的强依赖 —— 一旦你在生产 CLI 环境中运行这些命令，没有 pcntl 就无法优雅退出或处理中断。别只想着让 composer install 过掉，得确认后续运行时是否真能工作。
