Composer install –no-dev在部署流程中的重要性及常见误区

生产部署必须使用 composer install –no-dev，否则会安装 phpunit 等开发依赖，引入安全风险、增大镜像体积（30–200MB）、拖慢 autoload 生成，并可能因 dev 包污染自动加载导致类冲突或意外初始化。

为什么 composer install --no-dev 必须出现在生产部署中

不加 --no-dev 会导致生产环境安装开发依赖，比如 phpunit/phpunit、friendsofphp/php-cs-fixer、laravel/pint 等——这些包既不参与运行时逻辑，又可能引入安全风险、增大部署体积、拖慢 autoload 生成速度。

更隐蔽的问题是：某些 dev 包的自动加载规则会污染 vendor/autoload.php，导致类名冲突或意外触发初始化逻辑（例如某测试工具在加载时执行了文件系统扫描）。

• 生产镜像体积常因此增加 30–200MB（取决于项目依赖树深度）
• composer dump-autoload -o 在含 dev 包时可能失败或生成低效的 classmap
• 部分 CI/CD 流水线未清理 composer.lock 中的 require-dev 字段，导致误判依赖范围

composer install --no-dev 和 composer install --optimize-autoloader 的关系

两者不互斥，但顺序和组合影响结果。单独用 --no-dev 不会自动启用优化；必须显式加 --optimize-autoloader（或简写 -o）才能生成扁平 classmap、跳过 PSR-4 动态查找。

典型安全写法是：

composer install --no-dev --optimize-autoloader --no-interaction

• --no-interaction 防止因缺少交互输入（如 gitHub Token 提示）导致流水线卡住
• 若项目含大量 PSR-4 命名空间，-o 可提升类加载性能 15–40%
• 注意：-o 会忽略 autoload-dev 中的路径，所以它天然兼容 --no-dev

CI/CD 中容易漏掉的三个关键点

很多团队只在最后一步跑 composer install --no-dev，却忽略了前置条件是否干净。

• 没清空 vendor/ 或没删 composer.lock 就重装 → 可能残留旧 dev 包
• CI 使用的 PHP 版本高于生产环境 → 某些 dev 包的 platform 配置被绕过，导致本地能装、线上报错 Your requirements could not be resolved
• 误用 composer update --no-dev 替代 install → 会改写 composer.lock，破坏可重现性

验证是否真正生效的快速检查法

别只信日志里有没有 “Installing dependencies from lock file”，要看实际结果。

• 执行 ls vendor/ | grep -E '^(phpunit|php-cs-fixer|pestphp|laravel/pint)' | wc -l，输出应为 0
• 检查 vendor/composer/autoload_classmap.php 头部注释是否含 Generated by Composer 且无 dev 相关路径
• 运行 composer show --dev，应报错 There are no packages required in the require-dev section

最麻烦的情况是：某些包把开发工具塞进 require 而非 require-dev（比如旧版 monolog/monolog 的某些分支），这时光靠 --no-dev 拦不住，得人工审计 composer.json。