换镜像源本身不减体积，但能避免网络超时导致缓存失效，使vendor层反复重建并混入临时文件、tests/、docs/等冗余内容，最终间接增加100MB+体积。
用中文镜像本身不减体积，但能避免因网络超时导致的构建失败或重试——后者常让 Docker 缓存失效，间接引发 vendor 层反复重建，最终多出 100MB+。
为什么换镜像源对镜像体积有间接影响
Composer 官方源在国内下载慢，Docker 构建时容易触发超时或断连。一旦 composer install 失败，缓存链就断了；下次构建即使 composer.json 没变，也会重装整个 vendor/，失去层复用机会。而多阶段构建中，vendor/ 层是最大体积来源，缓存失效 = 白建一次。
- 超时后重试可能留下临时解压文件（如
/tmp/composer_archive*），若 builder 阶段没清理，会被 COPY 进 final 镜像 - 某些包在失败重试时会多下载
tests/或docs/目录（尤其未加--no-dev时） - CI 环境中频繁重试还可能触发 GitHub rate limit，被迫 fallback 到更慢的源，进一步拉长构建时间、增加失败概率
在 Dockerfile 中安全设置阿里云镜像源
必须在 builder 阶段、composer install 之前设置，且不能写死到全局配置里（否则可能污染缓存或影响其他阶段）。推荐两种方式：
- 用
RUN composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/—— 注意：只在 builder 阶段执行，final 阶段不运行此命令 - 或在项目根目录的
composer.json中声明（更推荐）："repositories": { "packagist": { "type": "composer", "url": "https://mirrors.aliyun.com/composer/" } }这样无需额外 RUN 指令，也避免了-g全局配置残留风险
别用 ENV COMPOSER_HOME=/tmp/composer 这类方式改路径——BuildKit 的 --mount=type=cache 依赖默认位置，改了反而让缓存失效。
镜像源 + 多阶段构建的组合关键点
单靠换源解决不了体积问题，必须配合多阶段构建的约束条件才能见效：
-
COPY composer.json composer.lock ./必须单独成层，且紧接在WORKDIR之后，前面不能有RUN chmod或COPY .gitignore等无关指令 -
RUN composer install --no-dev --optimize-autoloader --classmap-authoritative必须紧跟其后，中间插任何命令都会破坏缓存 - final 阶段的
COPY --from=builder必须精确到目录：COPY --from=builder /app/vendor /app/vendor，而不是COPY --from=builder /app .——后者会把 builder 阶段残留的.git、tests/、bin/全拖进来 - builder 阶段末尾建议加清理：
RUN find vendor/ -name '.git' -prune -exec rm -rf {} + 2>/dev/null || true
检查最终镜像是否真的“干净”
很多人以为用了多阶段就万事大吉，其实 final 镜像里还藏着几个典型隐形体积源：
-
/root/.composer：builder 阶段如果用了-g配置且没清理，可能被 COPY 进来 -
/tmp/composer*：安装失败残留的临时归档，builder 阶段应加RUN rm -rf /tmp/composer* -
vendor/bin/*：比如phpunit、phpcs，除非 runtime 真需要，否则删掉 -
vendor/*/tests/和vendor/*/docs/：即使加了--no-dev，部分包仍会带进来，需用find vendor -name 'tests' -type d -prune -exec rm -rf {} +清理
最稳妥的做法不是等构建完再查，而是在 builder 阶段结尾就执行清理，并用 docker build --progress=plain 观察每层大小，重点关注 vendor 层是否稳定在预期范围（通常 30–80MB，视依赖数量而定）。
