有效缓存 Composer 层需先复制 composer.json 和 composer.lock 并运行 install，再复制其余代码；使用多阶段构建剔除 dev 依赖和 Composer 二进制；确保 composer.lock 提交至版本控制并及时更新。
在 Dockerfile 中为 Composer 层做有效缓存，核心是分离依赖安装与应用代码变更，避免每次修改 PHP 文件都导致 composer install 重新执行。
只复制 composer.json 和 composer.lock
不要直接复制整个项目目录（如 COPY . /app），而应分步复制：先仅复制依赖声明文件，再运行安装，最后复制其余代码。这样只要 composer.json 或 composer.lock 不变，Docker 就能复用已构建的 Composer 层。
COPY composer.json composer.lock ./ RUN composer install --no-dev --no-interaction --optimize-autoloader COPY . .
使用多阶段构建减少镜像体积
生产镜像中无需 Composer 二进制、dev 依赖和源码缓存。用多阶段构建，在构建阶段安装依赖并生成 autoload，再将 vendor/ 和运行时文件复制到精简的最终镜像中。
FROM php:8.2-cli WORKDIR /app COPY composer.json composer.lock ./ RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer \ && composer install --no-dev --no-interaction --optimize-autoloader生产阶段
FROM php:8.2-cli-alpine WORKDIR /app COPY --from=0 /app/vendor /app/vendor COPY . .
确保 lock 文件存在且更新及时
Composer 缓存是否生效，高度依赖 composer.lock 是否被正确提交和更新。务必：
- 把
composer.lock加入版本控制（不可忽略） - 本地增删依赖后，运行
composer update或composer require更新 lock 文件 - CI/CD 流程中禁用
--ignore-platform-reqs等跳过校验的选项，防止因环境差异导致缓存层“假命中”
可选：挂载 vendor 到构建缓存（高级）
对于大型项目或 CI 场景，可配合 BuildKit 启用 Composer 的原生缓存目录（如 ~/.composer/cache），或通过 BUILDKIT_PROGRESS=plain + cache-from 复用远程缓存。但对大多数项目，精准控制 COPY 顺序已足够高效。
基本上就这些 —— 关键不是技巧多复杂，而是让 Docker 的分层机制真正“看懂”哪些变更会影响依赖，哪些不会。
