加-v参数可显示完整错误输出，定位真实失败原因；需确保autoload.php存在、PHP命令可执行、脚本显式返回非零退出码。
加 -v 参数看真实错误输出
Composer 默认静默吞掉子进程的 stderr，你只看到 Script xxx handling xxx failed，却看不到真正出错在哪。不加 -v 就调试，等于蒙眼修电路。
实操建议：
- 用
composer run test -v或composer install -v重试，强制显示完整命令和每条子进程的 stdout/stderr - 重点盯住报错前最后一行执行的命令，比如
php ./tests/run.php—— 这才是真凶入口 - 如果输出里出现
sh: php: not found或'php' is not recognized，说明 shell 找不到php可执行文件，不是脚本问题，是环境 PATH 缺失
确认 autoload.php 是否已生成
很多脚本（尤其是 post-install-cmd、post-update-cmd）会在 vendor/autoload.php 尚未生成时就被触发，一调用类就直接 Class not found。
实操建议：
- 检查脚本是否依赖自动加载：如果是
php scripts/check.php且里面用了new App\SomeClass()，就必须确保autoload.php存在 - 把关键脚本挪到
post-autoload-dump钩子下——它保证 autoloader 已就绪 - 或在脚本开头加防护判断：
if (!file_exists('vendor/autoload.php')) { echo "autoload missing"; exit(1); } - 注意：某些 IDE 或 CI 环境会覆盖当前工作目录（cwd），导致相对路径失效；Composer 默认以项目根为 cwd，但别假设它永远如此
检查 PHP 命令是否可执行、路径是否正确
php 命令在本地能跑，不代表 Composer 脚本里也能用。Windows、Docker、CI 环境常因 PATH 或 shell 解析规则不同而失败。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
常见现象与对策：
-
./vendor/bin/phpunit在 Windows 下报错：去掉./前缀，写成vendor/bin/phpunit -
sh: php: not found：改用全路径，如/usr/bin/php vendor/bin/phpunit；先用which php查路径 - 更稳妥方式：用 Composer 自带的二进制别名，如
vendor/bin/phpunit本身已带 shebang 和路径解析，比裸写php更可靠 - 避免在 script 中写
php -f ./some.php——-f不必要，且./在某些 shell 下反而引发解析异常
脚本退出码必须非零才能被 Composer 捕获
Composer 判断脚本成败，只看子进程退出状态码（exit code）。只输出错误信息、不 exit(1) 或抛异常，等于没报错。
关键点：
- PHP 脚本中检测失败后，必须显式
exit(1)；echo "fail";+ 无退出 = Composer 认为成功 - 在 Composer 脚本类方法中，推荐抛异常（如
throw new RuntimeException("xxx")），Composer 会自动捕获并转为错误退出 - Shell 脚本同理：末尾加
|| exit 1，例如php check-env.php || exit 1 - 别用
|| true掩盖问题——它会让 Composer 忽略真实失败，后续脚本照常执行，导致状态不可信
最常被忽略的是：你以为脚本“报错了”，其实只是 echo 了一行字，进程仍以 0 退出。Composer 的成败判断极其朴素，就看 exit code，不多也不少。
