必须加 --no-dev:生产环境装依赖的第一个纪律
先说一个核心判断:生产环境运行 `composer install`,**必须加上 `--no-dev`**。这不是可选项,而是安全基线。
如果不加,Composer 会默认把 phpunit、php-cs-fixer、lara vel-debugbar 这类包全部拖进 vendor 目录。不是“可能装”,是“一定装”——只要你的 `composer.lock` 文件里有 `packages-dev` 区块,它就不会放过任何一个 dev 包。

### 为什么默认安装会带 dev 依赖?
很多人以为 Composer 会看环境变量,比如 `APP_ENV=production` 或者 `COMPOSER_DEV=0` 就能自动跳过 dev 包——这是误解。Composer 根本不管这些。
它只认两样东西:一是 `composer.lock` 文件里记录的内容;二是你有没有传 `--no-dev` 参数。而绝大多数开发者在本地 `composer update` 时生成的 lock 文件,都会包含 `"packages-dev"` 区块。于是生产环境上线时,只要你不说“别碰 dev 那部分”,Composer 就全装。
另外有三件事需要厘清:
- `--optimize-autoloader`(或 `-o`)只优化自动加载速度,完全绕不开 dev 包
- `COMPOSER_NO_INTERACTION=1` 跳过交互式提问,对依赖范围零影响
- 有人问:能不能直接在 `composer.json` 里删掉 `require-dev` 字段?不行,本地开发依赖还靠它,而且 commit 后别人也没法用测试工具
### composer install --no-dev 到底干了什么
**它不是“尽量不装”,而是从依赖解析阶段就直接绕开了 require-dev 这块。** 具体来说:不下载、不解压、不写入 vendor、不注册它们的 autoload 映射——这个映射指的是 `autoload-dev` 下声明的路径,不会出现在 `vendor/autoload_static.php` 里。相当于从源头切断了 dev 依赖的生命线。
几个关键点:
- 生效前提是 `composer.lock` 里依然有 `packages-dev` 记录——`--no-dev` 不会报错,也不会去删 lock 文件,只是忽略它
- 如果 lock 文件里已经混进了 phpunit/phpunit,说明上次 `composer update` 时没加 `--no-dev`,得先清理掉再重新生成
- 它不影响 autoload-dev 路径本身的声明——比如 `"Tests\\": "tests/"` 仍然出现在 `vendor/autoload.php` 里。但关键是测试类库没装,所以 `class_exists('Tests\FooTest')` 可能返回 true(如果那个文件物理存在),可类里依赖的 phpunit 类则不存在,运行时就会静默失败
### Docker 和 CI/CD 里最容易漏掉的三件事
自动化流程里一旦漏掉 `--no-dev`,镜像体积直接多出 20–50MB,启动变慢,还可能暴露调试入口。经验上最容易出问题的是下面三个:
1. **Dockerfile 里只写 `RUN composer install --no-dev` 是不够的**。更稳妥的是组合命令:`RUN rm -rf vendor/ && composer install --no-dev --prefer-dist --optimize-autoloader --no-scripts`。先清空再安装,防止缓存复用导致旧包残留。
2. **CI 脚本中,安装之前最好确认 lock 文件是干净的**。可以加一行验证:`grep -q '"require-dev"' composer.lock && echo "lock is dirty" || echo "safe"`。如果输出 dirty,说明 lock 文件里混了 dev 依赖,需要先修复。
3. **多阶段构建时容易混淆**。build 阶段可以全量安装(含 dev),但 final 阶段用 `COPY --from=builder /app/vendor /app/vendor` 复制过来时,builder 阶段执行的命令必须带上 `--no-dev`。否则 Copy 过来的 vendor 还是带着 dev 包的。
### --no-dev 和 --production 是什么关系
两者完全等价。Composer 2.0+ 文档明确写了 `--production` 是 `--no-dev` 的别名。但注意:缩写 `--prod` 不存在,输错了会报 `Unrecognized option: --prod`。
一些建议:
- 日常推荐统一用 `--no-dev`,语义最清晰,新人一眼能看懂
- 已有 CI 脚本在用 `--production` 的话不必硬改,但新项目就别再用它了
- 它和 `composer dump-autoload --no-dev` 不是一回事。`dump-autoload --no-dev` 只删 autoload 映射,不删已安装的包;而 `install --no-dev` 是从源头就不让 dev 包落地
最后得说一个最容易被忽略的点:**`--no-dev` 只控制“装不装”,不控制“能不能加载”**。如果业务代码里硬编码引用了 `Tests\*` 或 `PhpCsFixer\*` 的类,即使 dev 包没装,autoloader 路径声明仍然存在,运行时也可能因为找不到类而静默崩溃。解决方案是依赖接口抽象,或使用 `class_exists()` 做兜底判断——不能只信一个参数就以为万事大吉。
本文转载于:https://www.php.cn/faq/2398339.html 如有侵犯,请联系zhengruancom@outlook.com删除。
免责声明:正软商城发布此文仅为传递信息,不代表正软商城认同其观点或证实其描述。