composer 通过 scripts 中的 post-install-cmd 钩子在 install 后自动执行 vendor/bin/phpunit --no-coverage，依赖已就绪且需 @php 显式调用；post-autoload-dump 不适用因 vendor/bin 尚未生成。
composer install 后自动触发 PHPUnit 测试的原理
Composer 本身不执行测试，但可通过 scripts 配置在生命周期事件（如 post-install-cmd）中调用外部命令。关键在于：必须确保 phpunit 可执行，且测试命令在项目上下文中能正确加载 autoloader 和配置。
在 composer.json 中配置 post-install-cmd 脚本
直接修改 composer.json 的 scripts 字段，添加 post-install-cmd 条目。注意两点：一是优先使用 vendor/bin/phpunit（本地安装），而非全局 phpunit；二是加 --no-coverage 避免因 Xdebug 或路径问题中断安装流程。
- 若 PHPUnit 已通过
require-dev安装，vendor/bin/phpunit一定存在 - 推荐写成
"post-install-cmd": ["@php vendor/bin/phpunit --no-coverage"]，用@php显式指定 PHP 解释器，避免 shell 环境差异 - 不要写成
"post-install-cmd": "phpunit"—— 全局命令不可靠，且 Composer 不保证 PATH 包含其路径 - 若测试失败，默认会中断
composer install流程；如需忽略失败，可追加|| true，但不建议用于 CI 环境
为什么 post-autoload-dump 不适合跑测试
post-autoload-dump 在生成 autoload 文件后触发，但它不保证依赖已全部下载或 vendor/bin 下的二进制文件已就绪。常见错误现象是：sh: vendor/bin/phpunit: No such file or directory。这是因为 post-autoload-dump 可能在 install 的早期阶段执行，而 vendor/bin 符号链接尚未创建。
-
post-install-cmd和post-update-cmd是唯一能确保vendor/bin/已就绪的钩子 -
post-autoload-dump更适合清理缓存、生成代理类等纯 PHP 操作 - 若同时监听多个钩子，注意执行顺序：
post-autoload-dump→post-install-cmd
CI 环境下更稳妥的做法：分离安装与测试
在 GitHub Actions、GitLab CI 等场景中，硬绑定 post-install-cmd 容易掩盖环境问题（比如缺少 ext-dom、ext-json）。真实项目应把安装和测试拆成独立步骤，便于定位失败环节。
- CI 脚本中显式写
composer install --no-interaction+vendor/bin/phpunit - 本地开发时可保留
post-install-cmd作快速验证，但不依赖它保证质量 - 若项目用了 PHPUnit 配置文件（
phpunit.xml或phpunit.xml.dist），确保它位于项目根目录，否则vendor/bin/phpunit可能找不到测试套件
phpunit/phpunit ^9 要求 PHP 7.3+，而某些旧项目 composer install 成功后，vendor/bin/phpunit 虽存在，但执行时抛出 ParseError，这种失败不会被 post-install-cmd 的错误提示明显标识出来。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
