composer require –dev仅将包写入require-dev字段，是否安装取决于composer install是否带–no-dev；生产环境必须加–no-dev –optimize-autoloader，否则dev包仍会被安装并加载。
require –dev 是把包装进 require-dev 字段，不是“只在开发环境生效”
很多人误以为 composer require --dev 装的包在生产环境就自动不加载、不安装——其实完全不是这样。composer install 默认会安装 require-dev 里的全部包，除非你显式加 --no-dev。真正起作用的是安装时的开关，而不是安装时用的命令。
常见错误现象：composer require --dev phpunit/phpunit 后，上线部署时没加 --no-dev，结果 phpunit 被一起打进生产镜像，既增大体积，又可能因 autoload 冲突或扩展缺失报错。
-
composer require --dev只影响composer.json中的字段位置（写入require-dev），不改变后续行为 - 是否安装 dev 包，由
composer install或composer update时是否带--no-dev决定 -
composer dump-autoload生成的 autoloader 会同时处理require和require-dev，除非用了--no-dev
生产部署必须加 –no-dev，否则 require-dev 包照装不误
CI/CD 流水线或 docker 构建中，如果只写 composer install，Composer 会读取 composer.lock 并安装所有依赖，包括 require-dev 下的包。这和本地 composer install 行为一致，没有“环境感知”逻辑。
正确做法是：在生产环境执行 composer install --no-dev --optimize-autoloader。
-
--no-dev：跳过require-dev字段下的所有包，也不加载它们的 autoload 规则 -
--optimize-autoloader：生成扁平化 classmap，提升性能；该选项在--no-dev下更安全，避免 dev 包的测试类被意外包含 - 注意：如果项目用了
autoload-dev（如测试目录映射），--no-dev也会让这些路径不被加入 autoloader
如何验证某包是否真的没被装进生产环境
别只信配置，要检查实际结果。最直接的方式是进生产容器或部署目录，确认包文件是否存在、能否被 autoload 加载。
- 检查 vendor 目录：
ls vendor/ | grep phpunit—— 如果输出非空，说明--no-dev没生效 - 检查 autoload_classmap.php：
grep -n "PHPUnit" vendor/composer/autoload_classmap.php—— 若有匹配，说明 dev 包仍参与了 autoloader 构建 - 运行时验证：
php -r "var_dump(class_exists('PHPUnitFrameworkTestCase'));"—— 生产环境应返回bool(false)
require-dev 不等于“仅开发用”，有些包必须谨慎归类
并不是所有开发工具都适合扔进 require-dev。比如 symfony/var-dumper 常用于开发调试，但若你在生产日志里也用它格式化变量，那它其实是 runtime 依赖，应放在 require；再比如 doctrine/migrations，虽然平时只在部署脚本里跑，但它执行的是数据库变更，属于生产流程一环，放 require-dev 会导致生产环境无法执行迁移。
判断依据只有一个：这个包的代码是否会在生产请求生命周期中被 PHP 执行（哪怕只是 include 或 class_exists）。
- 纯 CLI 工具（如
php-cs-fixer、phpstan）可放心放require-dev - 会被生产代码
use或new的类，必须放require - 通过
class_exists($name, false)动态探测存在的类，也要确保对应包在生产可用，否则逻辑分支失效
实际项目里，最容易被忽略的是 autoload-dev 和 –no-dev 的联动效果：一旦用了 --no-dev，autoload-dev 里声明的测试类路径就彻底从 autoloader 中消失——哪怕你没在生产代码里引用它们，某些框架的反射机制（比如 laravel 的测试辅助函数注册）也可能因此出问题。