必须用-vvv：它唯一能显示每条执行命令、完整环境变量及原始stderr，常见fatal error、parseerror等仅在此模式可见；php脚本需有shebang和可执行权限，windows应显式写php script.php。
脚本报错只显示 “Script failed” 怎么看真实错误
Composer 默认吞掉子进程 stderr，你只能看到 Script xxx handling yyy returned with error code 1，却不知道哪行 PHP 崩了。关键不是加日志，而是让错误原样透出：必须用 -vvv。
-vvv 是唯一能显示每条执行命令、完整环境变量、及其原始 stderr 的开关。常见真实错误（如 Fatal error: Uncaught Error:、ParseError、Class not found）只在 -vvv 下可见。
如果脚本是 PHP 文件，检查两点：
- 开头是否有
#!/usr/bin/env php（Linux/macOS 必须有） - 是否具备可执行权限：
chmod +x script.php - Windows 下别依赖 shebang，显式写
php script.php更稳
脚本执行权限被拒绝（Permission denied）
Linux/macOS 下运行 vendor/bin/phpunit 报 Permission denied，大概率不是目录权限问题，而是 ZIP 解压丢失了可执行位——Git 不跟踪 Unix 权限，每次 composer install 都会重置。
临时解法：chmod +x vendor/bin/phpunit（或批量 chmod +x vendor/bin/*）
一劳永逸：在 composer.json 中加钩子：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
"scripts": {
"post-install-cmd": "chmod +x vendor/bin/*",
"post-update-cmd": "chmod +x vendor/bin/*"
}
注意：该方式仅对 POSIX 系统生效；Windows 下直接用 php vendor/bin/phpunit 即可。
脚本里调用的命令找不到（Command not found）
报错含 sh: line 1: xxx: not found 或 Command 'phpunit' not found，本质是 PATH 没加载或命令不在环境里。
常见场景与对策：
- Jenkins 构建中直接写
composer test→ 改用绝对路径：php /opt/composer/composer.phar run-script test --no-interaction - 脚本里写
phpunit→ 改成vendor/bin/phpunit（确保它存在且有执行权）或php vendor/bin/phpunit（绕过 shebang 和 PATH） - Docker/CI 中 UID 错位导致
vendor/bin/*不可执行 → 启动容器时加--user $(id -u):$(id -g)，或先chown -R $USER:$USER vendor/
脚本执行卡住或无响应
脚本没报错但长时间挂起，通常是交互式行为未关闭，或子进程等待输入。
必须加 --no-interaction（简写 -n）：
composer run-script post-install-cmd -n-
php artisan migrate -n（若脚本里调用了 Laravel 命令） - 所有 CI/自动化场景下，任何可能触发确认（如
continue?）、密码提示、或 TTY 检测的命令都需加-n
另外检查脚本是否隐式依赖当前工作目录——用 pwd 和 ls -l composer.json 确认执行位置正确；必要时用 -d 显式指定目录，且确保 -d 在子命令前（如 composer -d ./app install，不能写成 composer install -d ./app）。
