require-dev 包安装在 vendor/ 目录，与普通包位置相同，仅语义上区分开发依赖；执行 composer install --no-dev 时跳过安装，CI/CD 常用此方式避免将测试工具等带入生产环境。
composer require-dev 装的包到底去哪了
装在 vendor/ 目录里，和普通包完全一样，只是记录在 composer.json 的 require-dev 字段下。Composer 不会为它们建单独目录，也不会限制运行时加载——关键区别只在安装逻辑和语义上。
- 执行
composer install时，默认装require+require-dev；加--no-dev才跳过require-dev -
composer update默认也更新require-dev下的包，除非显式加--no-dev - CI/CD 部署时常用
composer install --no-dev --optimize-autoloader，避免把测试工具、代码检查器等带进生产环境
require-dev 该放哪些包
只放「开发期需要、运行期绝对不依赖」的工具类包。一旦业务代码里直接 use 了某个 require-dev 包里的类，就属于误用——部署时可能直接报 Class not found。
- ✅ 合理：
phpunit/phpunit、phpstan/phpstan、friendsofphp/php-cs-fixer、mockery/mockery - ❌ 危险：
laravel/dusk（如果测试代码被入口文件引用）、barryvdh/laravel-debugbar（若未做环境判断就启用） - ⚠️ 边界情况：
doctrine/dbal有时被迁移工具依赖，但若你的up()方法里用了它，就得挪到require—— 因为迁移是运行期行为
本地装了 dev 包，线上却提示 Class not found
大概率是线上执行了 composer install --no-dev，但代码没做环境隔离。不是 Composer 没装对，而是调用逻辑越界了。
- 检查报错堆栈，确认出问题的类是否来自
require-dev列表中的包 - 搜索项目中是否在非测试文件（比如
app/Http/Controllers或config/）里直接 new 或 use 了 dev 包的类 - 用
composer show --dev看当前已装的 dev 包列表，对比composer.json是否一致 - 临时验证：在服务器上删掉
vendor/，执行composer install（不加--no-dev），看是否还报错——如果好了，就是环境策略和代码没对齐
composer create-project 怎么默认不装 require-dev
它本身不控制 dev 包开关，行为取决于目标项目的 composer.json 和你传的参数。想跳过 dev 包，必须显式加 --no-dev。
- 正确命令：
composer create-project laravel/laravel myapp --no-dev - 注意：有些包（如 Laravel 官方脚手架）的
composer.json把phpunit放在require-dev，但同时在autoload-dev里声明了测试类自动加载路径——这不会影响运行，但如果你删了--no-dev，就会多装一堆无用依赖 - 别信某些文档说 “create-project 默认不装 dev”，那是旧版或误解；从 Composer 2.0 起，它的行为和
install一致
