Composer报错“Fatal error: Uncaught”指向脚本文件，说明是composer.json中scripts定义的PHP脚本（如post-install-cmd）运行时抛出未捕获异常或调用不存在函数，非Composer自身崩溃；而“Call to undefined function proc_open()”则是PHP CLI环境禁用了proc_open等关键函数所致，需修改php.ini的disable_functions并重启服务。
报错里有“Fatal error: Uncaught”且指向某个脚本文件
这不是 Composer 本身崩溃，而是你在 composer.json 的 scripts 字段里定义的 PHP 脚本（比如 post-install-cmd）运行时抛出了未捕获异常或调用了不存在的函数。Composer 只是执行器，真正出问题的是你写的或第三方包带的脚本。
常见触发点：
-
require或include了不存在的文件（路径写错、大小写不一致、vendor/autoload.php 没被正确引入） - 脚本里用了 PHP 8.2+ 新增函数（如
str_contains()），但当前 CLI PHP 版本是 8.1 或更低 - 调用了扩展函数（如
imagick、grpc），但 CLI 模式下该扩展没启用（php -m和phpinfo()页面可能不同） - 脚本依赖了
$_SERVER或环境变量，但在 CLI 下为空，没做判空直接用
排查动作：
- 先临时禁用所有脚本：加
--no-scripts参数重试，如果composer install --no-scripts成功，就确认是脚本问题 - 逐个启用：在
composer.json中注释掉其他scripts，只留一个，再跑composer install定位具体哪条 - 手动执行脚本：找到报错行对应的 PHP 文件，用
php /path/to/script.php直接运行，错误更清晰
报 Fatal error: Call to undefined function proc_open()
这根本不是“脚本出错”，而是 PHP CLI 环境禁用了关键系统函数。Composer 安装器（install.php）和很多脚本（比如 Laravel 的 post-root-package-install）启动阶段就要调 proc_open() 启动子进程，一旦被禁，直接 Fatal。
验证方式：
- 运行
php -r "var_dump(function_exists('proc_open'));"，输出bool(false)就坐实了 - 检查
disable_functions：在 CLI 加载的 php.ini 里搜这一行，确认是否含proc_open、putenv、pcntl_signal
修复动作：
- 删掉
disable_functions中对应函数名（注意拼写、空格、逗号分隔） - 改完必须重启 PHP-FPM 或 Apache/Nginx；CLI 下还要新开终端或
source ~/.bashrc - 验证生效：
php -r "echo proc_open('echo 1', [], $p) ? 'ok' : 'fail';"输出ok才算真通
脚本报错但没明确行号，只显示“Class not found”
90% 是自动加载没生效，不是类文件丢了。Composer 脚本里用到的类（尤其是自定义命令或 post-install 逻辑）必须能被 vendor/autoload.php 正确加载，否则一运行就 Fatal error。
关键检查点：
- 确认
vendor/autoload.php是否被脚本require了——很多手写脚本漏掉这行 - 查
composer.json的autoload或autoload-dev段：PSR-4 映射末尾有没有多斜杠（"App\": "app//"）、命名空间大小写是否和目录名完全一致（Linux 区分大小写） - 运行
composer dump-autoload强制重建映射，尤其当你改过 autoload 配置后没重新生成 - 如果脚本在
vendor/bin下，确认它顶部的#!/usr/bin/env php后是否require __DIR__.'/../vendor/autoload.php';
CI/CD 里脚本报错，本地却正常
差异几乎全在环境上。CI runner（GitHub Actions、GitLab CI）默认没有用户态配置、没全局镜像、PHP 扩展集精简、甚至 /tmp 权限受限——这些都会让脚本在 CI 里突然 Fatal。
典型陷阱：
-
COMPOSER_HOME未设，导致全局配置（如镜像、auth）读不到，脚本里又硬编码了 packagist.org 请求 - 脚本里用了
shell_exec('git rev-parse HEAD')，但 CI 环境没装 git 或工作区没初始化（git clone没执行） - 写了
file_put_contents('/tmp/cache.json', ...)，但 CI runner 的/tmp是只读挂载 - 用了
$_ENV['APP_KEY']，但 CI 没注入该变量，也没设默认值，直接Undefined array key然后 Fatal
应对方式：
- CI 脚本开头加
php -v && php -m | grep -E "(curl|openssl|mbstring)"确认基础扩展存在 - 所有外部依赖（git、node、python）显式安装，别假设环境自带
- 脚本里所有
$_ENV、$_SERVER、文件路径操作，必须加isset()或is_writable()判空/可写 - 把脚本拆成独立可测的 PHP 文件，在 CI 里用
php script.php单独跑，比混在composer install里更容易定位
脚本类 Fatal 错误最麻烦的不是语法错，而是环境差一点、配置少一行、权限差一级，就卡在“看起来该成功”的临界点。盯住报错里第一个 Fatal error 行，它指哪儿就查哪儿，别绕开去重装 Composer 或清缓存——那只是转移注意力。
