根本原因是脚本执行失败且返回非零状态码，Composer 默认隐藏真实错误；加 -v 参数可显示完整输出，配合 --no-ansi、COMPOSER_MEMORY_LIMIT=-1 或修改 php 配置可进一步排查。
为什么 composer install 或 composer update 报 Script failed？
根本原因不是 Composer 本身出错，而是它执行的脚本（比如 post-install-cmd、post-update-cmd）中途退出且返回非零状态码。常见于 Laravel 的 php artisan optimize:clear、Symfony 的 cache:clear，或自定义的 php bin/build.php。
关键点：Composer 默认隐藏脚本真实输出，只报一句 Script failed，让人无从下手。
如何让失败脚本吐出真实错误？
加 -v（verbose）参数是最直接有效的方式，它会强制显示脚本的完整 stdout/stderr：
composer install -v
如果仍不明显，再叠加 --no-ansi 避免颜色干扰，或用 COMPOSER_MEMORY_LIMIT=-1 排除内存限制导致的静默中断：
COMPOSER_MEMORY_LIMIT=-1 composer install -vcomposer install --no-ansi -v- 若脚本是 PHP 命令，可临时在
composer.json中把"php xxx"改成"php -d display_errors=1 -d error_reporting=-1 xxx"
脚本里调用 php 命令失败的典型陷阱
Laravel/Symfony 项目中，artisan 或 console 脚本常因环境未就绪而崩，比如：
-
APP_ENV未设，导致配置加载失败（Class 'App\Providers\AppServiceProvider' not found） -
.env缺失或格式错误，引发DotenvInvalidPathException - 缓存目录（
bootstrap/cache/）不可写，config:cache直接退出 - PHP 扩展缺失（如
mbstring、xml），但脚本没做预检，报错晦涩
验证方式：手动运行该脚本命令，例如：php artisan config:clear，观察是否真能成功。
跳过脚本执行快速验证依赖安装是否正常
不是所有场景都需要立即跑脚本——比如只想确认包能否拉下来、autoload 是否生成正确：
-
composer install --no-scripts：跳过所有脚本（pre-/post-类） -
composer install --no-autoloader：连 autoload 文件都不生成，适合极端调试 -
composer dump-autoload -o单独运行，比install更轻量，适合检查类映射问题
注意：--no-scripts 不解决脚本本身的问题，但它能帮你快速区分：是依赖安装失败，还是脚本逻辑有问题。
最易被忽略的是脚本执行时的工作目录和环境变量——Composer 在不同阶段（install/update）启动子进程时，getcwd() 和 $_ENV 可能和你手动执行时不一致，建议在脚本开头加 echo "PWD: " . getcwd(); print_r($_ENV); 快速定位。
