加-v参数可查看真实错误输出，否则Composer会隐藏stderr导致排查困难；需检查PATH、autoload.php是否存在、工作目录、PHP路径及脚本退出码。
加 -v 参数看真实错误输出
不加 -v 就排查 composer run 报错，等于在黑盒里拧螺丝。默认情况下 Composer 会吞掉子进程的 stderr，你只看到 Script xxx handling xxx failed，但根本不知道哪行 PHP 报了 Fatal error 或 shell 找不到 php。
实操建议：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 立刻重试：
composer run test -v或composer install -v - 重点盯住输出末尾——尤其是最后几行，那里才是子命令真正崩溃的位置
- 如果看到
sh: php: not found或'php' is not recognized，问题不在脚本逻辑，而在环境 PATH 或 shell 解析
检查 autoload.php 是否存在且可加载
很多脚本（尤其是 post-install-cmd、post-update-cmd）会在 vendor/autoload.php 还没生成时就被触发。一旦脚本里写了 new App\SomeClass()，就会直接 Class not found。
实操建议：
- 在脚本开头加防护：
if (!file_exists('vendor/autoload.php')) { echo "autoload missing"; exit(1); } - 别依赖相对路径调用：写
php scripts/check.php前，确认当前工作目录是项目根（CI/IDE 可能覆盖 cwd） - 避免把需要类加载的脚本放在
pre-autoload-dump里——它天生早于 autoload 生成
确认 PHP 命令是否真能执行
php 命令在终端能跑，不代表 Composer 脚本里也能用。Windows、Docker、CI 环境常因 PATH 不一致或 shell 解析规则不同而失败。
实操建议：
- 用全路径替代命令名：先查
which php，再写成/usr/bin/php tests/run.php - 更稳妥：改用 Composer 自带的二进制别名，比如
vendor/bin/phpunit（注意别写成./vendor/bin/phpunit，Windows 下可能不认./前缀） - 若脚本中用了
@php，确保它指向的是可用 PHP 解释器（@php是 Composer 提供的 alias，不是系统命令）
脚本必须显式返回非零退出码
PHP 脚本里检测到错误后，只 echo "fail" 是没用的。Composer 判断成功与否，只看子进程的 exit code。没 exit(1)，就等于“成功”。
实操建议：
- 所有检查类脚本结尾必须有
exit(0)（成功）或exit(1)（失败） - 别信
die()或throw new Exception()的默认行为——它们不一定触发非零退出码 - CI 流程里尤其关键：如果
phpstan analyse找出 10 个错误却没exit(1)，整个 pipeline 会当作通过继续往下走
