根本原因是Docker构建时vendor/和Composer缓存无法跨层复用；需分层COPY composer.json/composer.lock→RUN composer install→COPY .，并忽略vendor/避免覆盖。
为什么 composer install 会重复下载依赖？
根本原因是 Docker 构建时每次 composer install 都在全新容器中执行，vendor/ 目录和 Composer 的全局缓存（~/.composer/cache）无法跨层复用。即使你把 composer.lock 复制进镜像，Docker 仍会因上层文件变动（比如改了 composer.json）导致后续所有 RUN 指令缓存失效。
如何用多阶段构建 + 分层 COPY 实现高效缓存？
核心思路是：把依赖安装和代码复制拆成两个独立层，并确保依赖层尽可能稳定。关键在于让 composer install 只依赖 composer.json 和 composer.lock，且这两个文件必须在 COPY 时单独、最早地进入构建上下文。
- 先
COPY composer.json composer.lock ./—— 这步触发缓存判断的唯一依据 - 再
RUN composer install --no-dev --prefer-dist --optimize-autoloader—— 此时若 lock 文件未变，Docker 会直接复用上一次构建的 vendor 层 - 最后
COPY . .—— 把源码复制进来，不影响前面的依赖层缓存
注意：不要在 composer install 前运行 composer update，否则锁文件会变，缓存必然失效。
如何避免 vendor 被 COPY . 覆盖或污染？
常见错误是把 vendor/ 放进项目根目录并提交到 Git，然后 COPY . . 会覆盖掉前面 composer install 生成的 vendor/。更糟的是，如果本地 vendor/ 权限或结构异常，还会污染镜像。
- 务必在项目
.dockerignore中加入vendor/、node_modules/、.git - 不要在
Dockerfile中用VOLUME或bind mount替代vendor/—— 运行时挂载会导致 autoloader 路径错乱、OPcache 失效 - 如需调试，可在构建后用
docker build --target dev ...定义一个带vendor/的临时 stage，但生产镜像必须从 clean install 构建
要不要用 BuildKit 的 cache mount？
可以，但要谨慎。BuildKit 的 --mount=type=cache 能模拟 Composer 全局缓存行为，减少包下载，但它不解决 vendor/ 层复用问题，且在 CI 环境中可能因缓存路径冲突导致不可预期行为。
RUN --mount=type=cache,target=/root/.composer/cache \
composer install --no-dev --prefer-dist --optimize-autoloader
实际效果取决于 CI 的构建节点是否共享 cache mount 存储。多数团队发现：单纯靠分层 COPY + 锁文件稳定，已能覆盖 90%+ 场景；引入 cache mount 反而增加调试成本，尤其当出现 Package foo has a PHP requirement incompatible with your PHP version 类错误时，很难区分是缓存污染还是环境不一致。
真正容易被忽略的是：composer install 的 --ignore-platform-reqs 选项会绕过 PHP 版本校验，导致镜像内依赖看似安装成功，运行时报 Class not found —— 这类问题不会出现在缓存逻辑里，但会让整个优化策略失效。
