composer require –dev 将包写入 require-dev 字段，仅开发环境安装；普通 require 写入 require 字段，生产环境也安装，误用会导致资源浪费与安全风险。
composer require –dev 是什么，和普通 require 有什么区别
composer require --dev 的作用是把包写入 composer.json 的 require-dev 字段，而不是 require 字段。这意味着该依赖只在开发、测试、CI 环境中安装，生产环境（比如执行 composer install --no-dev）会跳过它。
常见误操作是直接用 composer require phpunit/phpunit，结果它进了 require，导致线上也装了测试框架——既浪费资源，又可能引入非预期的自动加载或安全风险。
-
require：运行时必需的依赖，比如monolog/monolog、guzzlehttp/guzzle -
require-dev：仅开发阶段需要的工具，比如phpunit/phpunit、friendsofphp/php-cs-fixer、mockery/mockery - 执行
composer install默认会装两者；加--no-dev就只装require
如何正确添加 dev 依赖：命令与配置层面的操作
最常用方式就是显式加 --dev 参数：
composer require --dev phpunit/phpunit:^10这条命令会：
- 下载并安装包到
vendor/ - 把
"phpunit/phpunit": "^10"写进composer.json的require-dev块 - 更新
composer.lock，记录精确版本
如果想手动编辑 composer.json 再安装，也可以先加字段再运行 composer update --lock，但不推荐——容易漏掉依赖解析或版本冲突检查。
注意：composer require 默认行为是「修改 composer.json + 安装」，不是只改 JSON；若只想改 JSON 不安装，得加 --no-update，但后续必须手动 composer update vendor/name，否则 vendor 里没文件。
为什么有些包强制进 require-dev，而有些却不能加 –dev
某些包在设计上就禁止被放到 require-dev，比如 symfony/flex 或 laravel/pint ——它们在 composer.json 中声明了 "type": "composer-plugin" 或通过 extra.auto-scripts 注册钩子，必须在安装时可用。如果强行用 --dev 装，虽然命令能跑通，但后续 composer install --no-dev 会导致插件失效、脚本不执行、甚至项目无法 autoload。
判断一个包是否适合加 --dev，看它是否：
- 只在 CLI 下运行（如
php-cs-fixer、phpstan） - 只在测试中被引用（如
phpunit、prophecy） - 没有被
autoload或autoload-dev引入到主代码路径中 - 不提供运行时服务（比如不是中间件、命令、事件监听器）
不确定时，查它的 composer.json 源码，重点关注 autoload、type 和 extra 字段。
dev 依赖装错位置后怎么修复
如果已经误用 composer require phpunit/phpunit 把它装进了 require，别删 vendor 直接重装。正确做法是两步：
composer remove phpunit/phpunit composer require --dev phpunit/phpunit:^10
这样能确保：
-
composer.json中对应条目从require移到require-dev -
composer.lock正确更新依赖图谱 - vendor 中文件不变（Composer 会复用已下载的 zip），但 autoloader 会按新规则重建
如果项目用了 autoload-dev 映射测试类，还要确认 phpunit 相关的命名空间没被意外暴露到生产 autoloader 里——检查 vendor/composer/autoload_psr4.php 是否含 dev-only 的映射项，有则说明配置有问题。
dev 依赖最容易被忽略的点不是“装不装”，而是“什么时候不该装”：比如在 docker 构建多阶段镜像时，build 阶段装了 dev 依赖，但 final 阶段没清干净，就等于把 PHPUnit 打进了生产镜像。