生产环境Docker构建必须加--no-dev和--optimize-autoloader：前者跳过dev包避免autoload冲突与体积膨胀，后者生成静态类映射提升加载性能，缺一不可。
docker build 阶段必须加 --optimize-autoloader 和 --no-dev
不加这两个参数，生产镜像里的 vendor/autoload.php 会保留完整的 PSR-4 扫描逻辑，每次类加载都要遍历目录、拼路径、调 file_exists()。在容器里这开销不会被 opcache 缓存掉——因为扫描动作本身是 PHP 代码执行，不是文件读取。
正确做法是在 Dockerfile 的安装命令中固化：
RUN composer install --no-interaction --no-dev --optimize-autoloader --prefer-dist
注意三点：
-
--no-dev不只是省体积：dev 包的类不会进autoload_classmap.php，漏掉它会让 autoloader 回退到慢路径 -
--prefer-dist减少解压和 git clone 开销，对构建速度有实际影响 - 别用
composer dump-autoload -o替代 —— 它不重装包，新引入的依赖类不会被扫进 classmap
opcache 必须在容器内启用且预热
就算生成了 autoload_classmap.php，如果 PHP 的 opcache 没开或没热起来，vendor/autoload.php 和 autoload_classmap.php 还是每次请求都重新编译。你看到的“首字节延迟高”基本都卡在这儿。
检查并确保容器 PHP 配置含以下项：
opcache.enable=1-
opcache.enable_cli=1（CLI 场景如健康检查、队列任务也需要） -
opcache.memory_consumption=256（大项目至少 256M，否则 autoload 文件可能被挤出缓存） -
opcache.validate_timestamps=0（生产环境禁用时间戳校验）
部署后建议加一次预热脚本：
php -r "opcache_compile_file('vendor/autoload.php');"
别在运行时挂载 vendor 目录
本地开发常用 -v $(pwd)/vendor:/app/vendor，但在生产容器里这是性能杀手。尤其是 macOS/Windows 上，宿主机文件系统桥接导致 require 数百个类文件时 I/O 延迟飙升。
正确姿势：
- 构建阶段把
vendor完整打进镜像（上面RUN composer install已做到） - 运行时只挂载配置、日志、上传目录等动态内容
- 若真要热更新依赖（极少见），用多阶段构建 +
COPY --from=builder /app/vendor /app/vendor，而非绑定挂载
--classmap-authoritative 要慎用，但 CI/CD 里可强制开启
这个参数会让 autoloader 彻底跳过 PSR-4 fallback，只查 classmap。它确实能再省几毫秒，但代价是：只要 classmap 漏一个类（比如某库用了 files 加载全局函数，或测试类混进了主 autoload），就直接 Class not found，错误信息还不提示真实原因。
安全用法：
- CI/CD 流水线里加
--classmap-authoritative，配合严格测试覆盖（确保所有生产类都被静态发现） - 确认项目没用
"files": ["src/helpers.php"]类型加载（这类文件不会进 classmap，但会破坏权威性） - 检查
vendor/composer/autoload_real.php里findFile()方法：如果只剩$classMap分支，没有$prefixesPsr4循环，才算真正生效
最常被忽略的一点：Docker 构建时的 PHP 版本、扩展、工作目录，必须和运行时完全一致——否则 classmap 生成路径错位，上线就报错。
