预加载不加速构建，只优化PHP-FPM启动后类加载；真正缩短构建时间需减少依赖下载和类查找，配合composer dump-autoload --optimize --classmap-authoritative等措施。
预加载本身不突破网速限制，它解决的是容器启动后 PHP 类加载的 I/O 和解析开销；真正缩短构建时间的关键是减少运行时依赖下载和类查找——预加载只是其中一环，且必须配合其他优化才有效。
为什么 composer preload 在容器构建中常被误用
很多人以为在 Dockerfile 里加一句 composer preload 就能“加速构建”，但实际它生成的 vendor/preload.php 是给 PHP-FPM 启动时用的，对 docker build 阶段毫无作用。构建阶段耗时大头仍是 composer install 下载 + 解压 + 自动加载生成，而预加载文件此时还没生效。
- 预加载机制依赖 opcache.preload 配置，该配置只在 PHP-FPM master 进程启动时读取一次，
docker build中的临时 PHP 进程不会触发它 -
composer preload默认扫描app、config等路径，但容器构建时这些目录往往尚未完整复制（比如用 multi-stage 构建，源码在 builder 镜像，运行镜像里只有vendor） - 若在构建阶段强行生成 preload.php，但未同步更新 opcache.preload 指向路径或未重启 PHP-FPM，该文件等于白写
composer dump-autoload --optimize --classmap-authoritative 才是构建阶段真正该做的
这个命令生成静态映射表，让自动加载从“每次拼路径+查文件系统”变成“数组键值查找”，直接降低容器首次请求的延迟。但它有严格前提，不是加参数就万事大吉：
- 必须搭配
composer install --no-dev --optimize-autoloader，否则 dev 代码混入 classmap 会膨胀体积 -
--classmap-authoritative要求所有类严格符合 PSR-4，比如App\Controllers\对应src/Controllers/，不能有大小写错位或命名空间末尾漏反斜杠 - 如果项目用了
"files"自动加载（如全局函数文件），启用 authoritative 会导致这些文件不被加载，必须显式require到入口脚本中 - Composer 2.2+ 默认生成
autoload_static.php，比旧版autoload_classmap.php更轻量，无需再加-o；盲目加反而因全量反序列化拖慢冷启动
预加载真正起效的时机和配置要点
预加载只在 PHP-FPM 启动时执行一次，之后所有 worker 进程共享已编译的字节码。要让它在容器中生效，需确保三件事同时成立：
- PHP 配置中开启 opcache：设置
opcache.enable=1、opcache.enable_cli=0（CLI 不需要）、opcache.preload=/var/www/vendor/preload.php -
preload.php文件路径在容器内真实存在，且 PHP-FPM master 进程有读权限（常见坑：Docker COPY 权限为 root，但 www-data 用户无法读） - 预加载文件里不能包含动态逻辑（如
if (env('APP_ENV') === 'local')），因为它是 FPM 启动时执行的，环境变量可能未完全加载 - 推荐用
"mechanism": "compile"（默认），避免require_once引发的潜在加载顺序问题；若项目含大量.inc或.module文件，需在extra.preload.extensions显式声明
预加载效果高度依赖项目结构干净程度——测试文件、文档、废弃模块一旦被扫进 preload.php，不仅浪费内存，还会因 opcache 缓存失效导致后续请求变慢。最容易被忽略的一点是：它和 opcache.revalidate_freq=0 必须配合使用，否则修改代码后 preload 不会自动刷新，得手动 kill -USR2 重启 PHP-FPM。
