Composer如何禁止在生产环境安装测试工具包？（上线必读）

composer install 默认安装 require-dev 包，生产环境应使用 composer install --no-dev 跳过 dev 依赖及 autoload-dev，需在部署、CI/CD、Docker 中显式添加，不影响 composer.lock。 composer install 时跳过 require-dev 的包 生产环境运行 默认仍会装 下的包，除非明确告诉它别装。这不是 bug，是默认行为——Composer 假设你本地和线上都走同一套流程，但上线时显然不该带 、 这类工具。 正确做法是加 参数： 这个参数会跳过 区块里的所有依赖，同时还会忽略 的自动加载规则，避免意外引入测试类。 必须在部署脚本、CI/CD 流水线、Docker 构建阶段显式加上，不能依赖“线上环境没装 dev 包”这种侥幸 如果项目用了 ， 不影响 lock 文件内容，只是安装时过滤掉 dev 依赖 某些旧版 Composer（--no-dev 下仍可能加载部分 dev autoloader，升级到 2.x 可彻底规避 为什么 vendor/bin 里还残留测试命令？ 即使加了 ，你仍可能在 看到 、 这些可执行文件——它们不是被“安装”进 vendor，而是由其他已安装的包（比如 或 ）声明的 bin 脚本，Composer 会一并生成符号链接。 这不是错误，但有风险： 如果某天误执行 ，它可能因缺少依赖而报错，也可能意外触发本地测试逻辑 更糟的是，某些框架（如 Laravel）的 Artisan 命令会扫描 ，遇到异常脚本可能提前失败 解决方案不是删文件，而是用 配置把 bin 脚本挪到非 Web 可访问路径，并配合部署脚本清理无关 bin CI/CD 中忘记 --no-dev 导致线上体积暴增 一个典型现象：Docker 镜像大小突然多出 80MB， 显示 、 占大头——基本就是 CI 脚本漏了 。 Composer 2.9.6 Composer 2.9.6 是 PHP 生态中高效、稳定的依赖管理工具。此版本在性能与兼容性上进一步优化，改进了依赖解析算法，提升大型项目中的安装与更新速度。它支持并行下载任务，显著减少等待时间，并增强了与私有仓库及镜像源的交互稳定性。同时修复了多项命令行交互与内存使用相关的缺陷，确保在复杂依赖关系下依然可靠运行。无论是新项目初始化还是现有系统维护，Composer 2.9.6 都能为开发者提供流畅、精准的依赖管理体验。 下载 这类问题往往只在上线后才暴露，因为本地开发不关心体积，测试环境又常复用 dev 依赖。 GitLab CI / GitHub Actions 的部署 job 必须显式写 很关键：它生成 classmap，绕过 PSR-4 动态查找，既提速又避免加载 dev 目录下的类（哪怕它们物理存在） 若用 后仍发现 dev 类可被 new 出来，大概率是 autoloader 没刷新，删掉 和 再重装 require-dev 里混进了运行时依赖怎么办？ 有些团队把 、 甚至 适配包扔进 ，结果上线后迁移跑不了、队列起不来——这不是 Composer 的锅，是依赖分类错了。 判断标准很简单：只要代码里 、 、 到它，或者它参与请求生命周期（如中间件、命令、事件监听器），就必须进 。 、 、 —— 安全放 dev 、 —— 运行时用，必须移出 dev 不确定？用 或直接查类是否在 的 autoload 链路中 最麻烦的不是改配置，是改完要验证所有命令、API、后台任务是否还能正常调用那些类——漏测一个，上线就挂。