Composer脚本报错应先用-v参数查看详细输出，检查autoload.php是否存在、路径是否正确、PHP命令是否可执行、脚本顺序是否合理、函数是否被禁用，并确认环境依赖如node和allow_url_fopen。
composer scripts 报错时，先看 composer run 的输出细节
Composer 脚本失败往往不是脚本本身有问题，而是执行环境或上下文缺失。默认 composer run（或 composer run-script）会静默吞掉子进程的 stderr，导致你只看到“Script xxx handling xxx failed”，却看不到真实错误。
实操建议：
- 加
-v参数重试：composer run test -v，强制显示完整命令和子进程输出 - 如果脚本调用的是 PHP 命令，注意它是否依赖
autoload.php—— 某些脚本在 vendor/autoload.php 未生成时就运行（比如post-install-cmd早于 autoload 生成），会直接报Class not found - 检查脚本是否用了相对路径（如
php ./tests/run.php），而当前工作目录是项目根？Composer 执行脚本时 cwd 是项目根，但某些 IDE 或 CI 环境可能覆盖了它
script 定义里用了 php 但没指定可执行路径，容易在 Windows 或容器里挂掉
常见现象：本地 Mac/Linux 正常，CI 或 Windows 下报 'php' is not recognized as an internal or external command 或 sh: php: not found。这不是 Composer 问题，是 shell 找不到 php 可执行文件。
实操建议：
- 用
php全路径代替命令名：查一下which php或where php，然后写成/usr/bin/php tests/run.php - 更稳妥的做法是用 Composer 自带的
php二进制别名：vendor/bin/phpunit这类命令天然带路径，或改用php -d memory_limit=-1 vendor/bin/phpunit - 避免在 script 中写
./vendor/bin/phpunit—— 某些旧版 Composer 在 Windows 下不识别./前缀，直接写vendor/bin/phpunit
composer.json 里的 script 配置顺序影响执行结果
Composer 不按书写顺序执行 scripts，但某些事件钩子（如 pre-autoload-dump）必须在 autoload 生成前完成，而 post-autoload-dump 依赖它。如果脚本逻辑跨阶段，顺序错乱会导致类加载失败或配置未生效。
实操建议：
- 不要把生成配置文件的脚本（如
php scripts/gen-config.php）放在post-autoload-dump里——它可能被缓存跳过；改到post-install-cmd或post-update-cmd - 若脚本需确保 autoload 已就绪，显式加依赖判断：
if [ -f "vendor/autoload.php" ]; then php test.php; else echo "autoload missing"; exit 1; fi - 用
composer show --scripts确认当前注册的 hooks 和自定义脚本名是否拼写一致（大小写敏感、空格、连字符都算不同）
脚本里调用 exec() 或 shell_exec() 出问题，多半是 PHP 禁用了这些函数
不少共享主机或 Docker 基础镜像（如 php:alpine）默认禁用 exec、shell_exec、system 等函数。Composer 脚本看似执行了，实际卡在 silent fail，返回码却是 0。
实操建议：
- 在脚本开头加检测：
if (!function_exists('exec')) { die("exec() disabled\n"); } - 改用
proc_open()替代 —— 它更可控，且多数环境不禁用（只要 proc_open 本身没被禁） - 如果是 Laravel Mix、Vite 等前端构建脚本失败，别急着查 JS，先确认
node是否在 PATH 里，以及allow_url_fopen是否开启（某些包会通过 HTTP 加载配置）
真正麻烦的从来不是报错信息，而是那些没报错却没干成事的情况 —— 尤其当脚本里混用了 shell 重定向、后台进程、信号处理时，Composer 默认不会等它们结束。
