开发环境不该用 --no-dev 安装依赖，否则会导致测试工具缺失、IDE无法跳转、autoload-dev映射失效却仍注册等严重问题；仅在复现生产环境、排查冲突或CI分阶段构建时才需谨慎使用。
开发环境里不该用 --no-dev 安装依赖——它会直接破坏本地开发能力，比如测试跑不起来、调试器失效、IDE 无法跳转测试类。真要“排除 dev 依赖”，只在特定场景下有意义，且必须清楚代价。
为什么开发环境通常不能加 --no-dev
加了 --no-dev 后，phpunit、mockery、phpstan、laravel/pint 这些包根本不会进 vendor/，连带它们的二进制命令（如 vendor/bin/phpunit）也不存在。更隐蔽的问题是：autoload-dev 里的 PSR-4 映射（比如 "Tests\": "tests/"）虽还在 vendor/autoload.php 中，但因为类文件没被安装，class_exists('TestsFooTest') 会返回 false，导致某些条件判断逻辑意外跳过。
常见误操作：
- 在本地执行
composer install --no-dev后发现phpunit命令报错 “command not found” - 运行
composer test失败，提示Class 'PHPUnitFrameworkTestCase' not found - IDE 提示测试类无法解析，但
composer.json明明写了require-dev
哪些开发场景才需要临时排除 dev 依赖
不是为了“省空间”或“提速”，而是为复现生产环境行为、验证 autoload 隔离、或调试依赖冲突。此时应明确目的，而非默认开启。
-
验证生产环境是否真能跑通：在本地模拟线上部署流程，运行
composer install --no-dev --optimize-autoloader，再手动删掉vendor/autoload.php中的autoload-dev映射（或执行composer dump-autoload --no-dev），看应用是否崩溃 -
排查 autoload 冲突：当怀疑某个
dev包的类路径污染了生产类加载（例如symfony/var-dumper被误用于线上日志），可先rm -rf vendor/，再用--no-dev重装，观察问题是否消失 -
CI 中的测试镜像构建：某些 CI 流水线会分阶段——先用
composer install装全量依赖跑单元测试，再用composer install --no-dev构建精简镜像供集成测试用。注意这是两个隔离步骤，不是替代本地开发
如何安全地在开发中“绕过”某个 dev 包
Composer 没有 --exclude phpunit 这种语法。想让某个 dev 包不参与当前安装，只能靠“不写入”或“后清理”：
- 把不想装的包从
require-dev移到require下的provide字段（不推荐，语义错乱） - 用
composer require --dev --no-install phpunit/phpunit先写入composer.json，但不实际安装；后续用脚本清理：rm -rf vendor/phpunit（Linux/macOS）或rd /s /q vendorphpunit（Windows） - 在
composer.json的scripts里加post-install-cmd，自动删指定目录（需谨慎，可能误删）
更稳妥的做法是：别动 require-dev，改用 config.platform 锁定扩展依赖（如 "ext-xdebug": "0"），让 Composer 解析时直接跳过需 xdebug 的 dev 包——这比事后删除更干净。
最容易被忽略的坑：autoload-dev 残留
--no-dev 只控制“装不装”，不控制“映射不映射”。哪怕 phpunit 没进 vendor/，只要 composer.json 里还写着 "autoload-dev": {"psr-4": {"Tests\": "tests/"}}，vendor/autoload.php 就仍会注册这个路径。结果就是：new TestsFooTest() 报错，但 class_exists('TestsFooTest') 返回 true（因为 autoloader 找到了路径，只是文件不存在）。这种不一致会让条件判断逻辑出错，线上难复现。
真正该做的：在开发环境保持 autoload-dev 完整；在线上部署时，用 composer dump-autoload --no-dev 彻底清除 dev 映射——这不是可选项，是隔离的关键一步。
