生产部署必须加 --no-dev，它跳过 require-dev 包安装，但依赖 composer.lock 不含 dev 信息；环境变量 COMPOSER_NO_DEV 易污染，应优先显式使用参数。
部署时用 composer install 默认会装 require-dev 里的包，这不仅浪费空间、拖慢速度，还可能引入非生产环境才该有的工具（比如 phpunit、symfony/debug-bundle），甚至带来安全风险。直接加 --no-dev 就能跳过开发依赖，但得清楚它在哪生效、怎么配合其他参数用才稳妥。
什么时候必须加 --no-dev
只在生产环境部署阶段需要——也就是服务器上运行 composer install 的时候。本地开发、CI 构建测试镜像、或运行 composer update 时通常不该加，否则会导致 autoload-dev 失效、测试类找不到等问题。
-
composer install --no-dev：仅跳过require-dev安装，但会读取composer.lock中已记录的 dev 包信息（只要 lock 文件里没 dev 包，就彻底不装） -
composer install --no-dev --ignore-platform-reqs：加了平台要求忽略，适合部署到 PHP 版本略低但实际能跑的服务器（慎用，别绕过关键限制） - 如果项目用了
config.platform模拟生产环境 PHP 版本，--no-dev仍需显式声明，它不自动继承 platform 配置
--no-dev 和 COMPOSER_NO_DEV 环境变量的区别
命令行参数 --no-dev 是最直接、最可控的方式；环境变量 COMPOSER_NO_DEV=1 虽然也能生效，但容易被忽略或污染：
- 环境变量对当前 shell 及所有子进程全局生效，可能意外影响 CI 脚本中其他 composer 命令
- Docker 部署时若在
Dockerfile里写ENV COMPOSER_NO_DEV=1，后续调试进容器执行composer install也会被强制 no-dev，不方便临时验证 - 推荐始终显式写
--no-dev，尤其在部署脚本、CI YAML、Dockerfile 的RUN指令里
为什么 composer install --no-dev 有时还是装了 dev 包？
常见原因不是参数失效，而是 composer.lock 文件本身有问题：
- 本地开发机上执行过
composer update没加--no-dev，导致 lock 文件里记录了 dev 包的版本和哈希 —— 此时即使部署时加--no-dev，composer 仍会按 lock 文件“确保一致性”，只是不 autoload dev 包，但部分包可能已被解压到vendor/ - 检查方法：运行
composer show --dev（本地）或直接看composer.lock里是否有packages-dev字段 - 修复方式：部署前确保 lock 文件由带
--no-dev的composer update生成，或 CI 中先运行composer update --no-dev --lock再提交 lock
真正干净的生产部署，关键不在参数本身，而在于 lock 文件是否从一开始就没混入 dev 依赖 —— --no-dev 只是最后一道闸门，不是过滤器。
