composer默认不安装require-dev依赖到生产环境，需显式加–dev或设composer_dev=1；composer require –dev会修改composer.json、执行update并更新autoload；phpunit类找不到常因版本不匹配、autoload未加载或ide缓存。
dev依赖装不进生产环境？先看COMPOSER_DEV环境变量
装了--dev依赖却在vendor/里找不到，大概率是执行时COMPOSER_DEV=0或--no-dev被隐式启用。Composer默认只在开发环境装require-dev里的包，但这个“环境”不是靠APP_ENV判断的，而是看当前是否启用了开发模式。
- 本地运行
composer install时，默认启用--dev，所以require-dev会装 - CI/CD 或线上部署常加
--no-dev，此时composer require --dev虽然能写进composer.json，但vendor/里不会实际安装 - 想强制装dev依赖，得显式加
--dev：比如composer install --dev或composer update --dev -
COMPOSER_DEV=1环境变量可覆盖命令行参数，但优先级低于--dev/--no-dev
composer require --dev到底改哪几处？
它不只是往require-dev里加一行，还会触发依赖解析和自动安装。很多人以为只是改JSON，结果发现没生成autoload、也没下载包，其实是漏了后续动作。
- 修改
composer.json的require-dev字段，新增包名+版本约束 - 立刻执行
composer update（带--dev上下文），下载包并更新vendor/ - 重写
vendor/autoload.php，把新包的PSR-4/Autoload配置加进去 - 如果该包含
scripts或extra配置（如phpunit路径），也会被合并进composer.lock
为什么phpunit装了却报class 'PHPUnitFrameworkTestCase' not found？
常见于用composer require --dev phpunit/phpunit后直接跑测试，但没注意PHP版本或自动加载时机。
- 检查
phpunit版本是否匹配当前PHP：PHP 8.2+ 要用^10.0，PHP 7.4–8.1 推荐^9.5；错配会导致安装失败或类不可见 -
vendor/autoload.php必须在测试启动前require，不能只靠Composer自动加载机制“猜”到你用它 - 某些IDE（如phpstorm）缓存了旧的autoload映射，改完
composer.json后要手动刷新Composer auto-loader（菜单：Tools > Composer > Dump Autoloader） - 如果项目用了
autoload-dev，确保测试文件在它的psr-4路径下，否则类不会被注册
想临时用dev包但不提交到composer.json？别用--dev
有人想“试用一下mockery”，又怕污染composer.json，于是加--dev再删，结果composer.lock已变、CI构建失败——这是典型误用场景。
-
--dev本质是长期依赖声明，不是“临时开关”。真要临时用，直接composer require mockery/mockery（不加--dev），用完composer remove mockery/mockery - 更安全的做法：用
composer create-project拉个干净副本做验证，或在docker run --rm -v $(pwd):/app composer:2里跑实验 - 如果只是需要某个工具二进制（如
php-cs-fixer），考虑用composer global require，但注意全局bin路径是否在$PATH里
dev依赖不是开关，是契约。改composer.json那一刻，你就承诺这个包会在所有开发机器上存在——包括队友的、CI的、甚至你下周重装系统的笔记本。