生产环境必须强制使用--no-dev和--optimize-autoloader：前者杜绝dev依赖引入的安全风险、性能损耗与运行时冲突，后者通过预生成类映射和PSR-4哈希表将类加载耗时从0.8–2.1ms降至0.03–0.07ms。
生产环境必须加 --no-dev 和 --optimize-autoloader，否则会引入安全隐患、启动变慢、内存占用升高，且可能因 dev 依赖冲突导致运行时失败。
为什么 --no-dev 不是可选项而是强制项
dev 依赖（如 phpunit、mockery、symfony/debug-bundle）在生产环境毫无用途，反而带来三重风险：
- 暴露测试类或调试工具入口（例如某些包注册了未受保护的路由或命令）
- 增加自动加载器扫描路径和类映射体积，拖慢
class_exists()和new操作 - 若某 dev 依赖含严重漏洞（如旧版
sebastian/environment），会被 Composer 自动包含进 autoloader，绕过安全扫描覆盖范围
执行 composer install --no-dev 后，vendor/autoload.php 不再加载 require-dev 下的任何包，composer.lock 中的 dev 依赖条目也不会被解析安装。
--optimize-autoloader 实际做了什么
它触发两个关键优化：
- 生成扁平化的
vendor/composer/autoload_classmap.php，把所有 PSR-0/4 类路径预编译为['ClassName' => '/path/to/file.php']数组，跳过文件系统遍历 - 将 PSR-4 映射转为「前缀 → 路径」哈希表，避免每次
new Foo\Bar都要逐个检查src/、lib/等目录
这对高并发请求尤其明显：未启用时，单次类加载平均多花 0.8–2.1ms（取决于 vendor 规模）；启用后稳定在 0.03–0.07ms。注意：该选项仅对 PSR-0/4 有效，files 类型自动加载不受影响。
CI/CD 流水线中必须配对使用的命令
单独运行 composer install --no-dev --optimize-autoloader 在 CI 中容易出错，需配合以下约束：
- 确保
composer.lock已提交且由开发环境生成（即已运行过composer update或composer install）——否则--no-dev可能漏装某些本应进入 production 的依赖 - 禁止在生产部署脚本里执行
composer update，哪怕加了--no-dev—— 因为update会改写lock文件，破坏可重现性 - 若用 Docker，应在构建阶段而非容器启动时运行该命令，并删掉
composer.json和composer.lock（减少镜像攻击面）
composer install --no-dev --optimize-autoloader --no-interaction --quiet
--no-interaction 防止卡在 prompt（如平台配置询问），--quiet 减少日志噪音，适合自动化场景。
常见误操作与静默失效点
这几个情况会让上述参数“看似生效实则无效”：
-
autoload-dev里声明了生产代码路径（例如误把"tests/": "src/"写成"src/": "src/"）→ 即使--no-dev，这些类仍被加载 - 项目使用了
classmap并指向了含测试文件的目录（如"classmap": ["tests/"]）→--no-dev不影响 classmap 扫描结果 - PHP OPcache 未启用或
opcache.enable_cli=1未设（CLI 模式下 autoload_classmap.php 若未被缓存，优化效果打五折）
验证是否真正生效：部署后检查 vendor/composer/autoload_classmap.php 是否存在且非空，再用 grep -r "PHPUnit" vendor/ 确认无测试框架残留。
