如何利用Composer管理项目中的单元测试依赖
一个关键原则必须牢记：PHPUnit 必须装进 require-dev，绝不能放进 require。否则，生产环境会平白多出一堆无用包，不仅浪费资源，还可能引发棘手的自动加载冲突。
为什么 composer require phpunit/phpunit 是错的
这条看似简单的命令，其实暗藏玄机。它默认会将 PHPUnit 写入 composer.json 的 require 区块，使其摇身一变成为“生产依赖”。后果是什么？即便你在线上执行 composer install --no-dev，它依然会被拉取下来。这不仅仅是浪费带宽和存储空间，更可能污染部署包，甚至引发 autoloader 冲突——例如，与 phpspec/prophecy 这类包发生类名冲突。
- 正确命令是：
composer require --dev phpunit/phpunit - 如果已经误装，先运行：
composer remove phpunit/phpunit，然后加上--dev参数重新安装。 - 版本匹配不容忽视：PHP 7.4 项目请使用
phpunit/phpunit:^9.6，只有 PHP 8.1 及以上版本才能使用 v10+。
autoload-dev 不配，tests/ 里的类就找不到
Composer 的自动加载器默认只关心 src/ 目录下的类。你的测试用例都放在 tests/ 里，如果不显式告诉加载器去扫描这个目录，那么 Class ‘AppTestsExampleTest’ not found 这类错误就会频繁出现。
- 解决方案是在
composer.json的autoload-dev部分添加 PSR-4 映射："App\Tests\": "tests/"。 - 修改完成后，务必立即执行：
composer dump-autoload（注意，不是install或update）。 - 别图省事只配置
autoload—— 它通常不包含tests/目录，而且某些测试框架（如 PHPUnit）会直接跳过它。
phpunit.xml 里 bootstrap 路径写错，TestCase 都加载不了
没有 phpunit.xml 配置文件，测试也能跑，但默认行为极其不可控：它会递归扫描当前目录下所有 *Test.php 文件，结果很可能误加载 vendor/ 目录里的测试文件，或者漏掉你自己的测试。
- 一份最小可用的配置必须包含
bootstrap="vendor/autoload.php"，这确保了 Composer 的自动加载器能优先就绪。 - 使用
tests - 放弃使用全局的
phpunit命令——它不会读取当前项目的phpunit.xml和autoload.php，版本也不受项目控制。 - 统一的执行命令应该是：
./vendor/bin/phpunit（Linux/macOS）或vendorinphpunit（Windows）。
composer test 脚本失效，八成是权限或路径问题
很多人习惯在 composer.json 的 scripts 里配置 "test": "vendor/bin/phpunit"，却在 Windows 上运行失败，或者遇到 “command not found” 的提示。
- Linux/macOS 用户：请确认
vendor/bin/目录下的文件具有可执行权限（可运行chmod +x vendor/bin/phpunit）。 - Windows 用户：实际被调用的是
vendor/bin/phpunit.bat批处理文件。虽然在脚本里写vendor/bin/phpunit也能工作，但必须确保这个 .bat 文件确实存在。 - CI/CD 场景建议：加上
--no-coverage参数，避免因为环境缺失 xdebug 扩展而导致测试过程中断。 - 执行前务必确认：
composer install --dev已经运行，并且vendor/bin/phpunit这个文件真实存在。
最后，还有一个最容易被忽略的陷阱：当你在测试中模拟（Mock）一个第三方类（例如 GuzzleHttpClient），而这个类又恰好来自 require-dev 中的依赖包（比如 guzzlehttp/guzzle）时，这个被模拟的包就不能仅仅出现在 require 里。否则，本地测试一切顺利，到了 CI 环境却会报出 Class not found 的错误。开发依赖的类路径，必须由 autoload-dev 来覆盖，绝不能指望生产环境的 autoload 机制替你兜底。
