如何使用Composer的--no-dev选项来减小生产环境的包体积？

本文共计866个文字，预计阅读时间需要4分钟。

--no-dev 不是“可选优化，而是生产环境部署的强制要求；不包含它，vendor 目录体积、安全隐忧、autoload 性能三者全盘崩溃。”

为什么 --no-dev 会导致 Class not found？

常见错误不是参数没生效，而是误以为 --no-dev 只删包——它实际会跳过整个 autoload-dev 块，连带把测试类、假数据工厂、调试服务提供者等注册规则一并剔除。一旦代码里写了 new TestsHelpersStub() 或在 AppServiceProvider::boot() 中绑定了只存在于 dev 包里的接口实现，就会直接报错。

• 检查 composer.json 是否含 "autoload-dev": {"psr-4": {"Tests\": "tests/"}} —— 如果有，且没加 --no-dev，这些路径会进 autoload_classmap.php，白占内存
• 运行 composer install --no-dev 后，确认 vendor/composer/autoload_static.php 里没有 Tests\ 开头的映射项
• 若仍报错，用 grep -r "Tests\\Helper" vendor/composer/ 看是否残留了未清理的 autoload 规则

--no-dev 和 autoload_classmap.php 的真实关系

--no-dev 不生成 classmap，但它决定 classmap 里“能塞什么”。所有被 require-dev 引入的包（如 phpunit、larastan）及其依赖，其 autoload 配置全部失效，自然也不会被扫描进 autoload_classmap.php。所以 classmap 文件体积变小，反序列化更快，更重要的是：它不再为根本不会部署的类预留空间。

• 对比命令：composer install --optimize-autoloader vs composer install --no-dev --optimize-autoloader，后者生成的 autoload_classmap.php 通常小 30%～60%
• classmap 越大，PHP 每次请求 require 它时解析开销越高；而实际单次请求用到的类往往不到总量的 5%
• 别信 "optimize-autoloader": true 写在 composer.json 里就万事大吉——它只是默认开关，不触发任何实际动作

CI/CD 流水线里漏掉 --no-dev 的典型后果

本地开发能跑通，线上炸锅，90% 是因为 CI 脚本用了 composer install 而非 composer install --no-dev。这不是兼容性问题，是物理层面的缺失：dev 包根本没装，它的类文件压根不存在于 vendor/ 里。

• 现象：Laravel 报 Class AppProvidersTestHelperServiceProvider not found，但该类明明在 app/Providers/ 下——其实是这个服务提供者只在某个 require-dev 包中注册，而那个包没装
• 验证方式：部署后立刻执行 ls -la vendor/phpunit，如果目录存在，说明 --no-dev 没生效
• CI 脚本里别依赖 COMPOSER_NO_DEV=1 环境变量——它在 Composer 2.2+ 已被弃用，且容易被其他插件覆盖

真正要盯住的不是“有没有加参数”，而是 vendor/ 目录里有没有不该出现的东西。哪怕命令写对了，如果前一次部署残留了 vendor/bin/phpunit 或 vendor/symfony/debug-bundle，风险仍在。精简不是一步操作，而是每次部署都必须重校验的物理状态。