必须在dockerfile的run指令中显式配置镜像源，因容器构建使用独立环境，宿主机的composer config -g对容器完全无效；需执行run composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/且url末尾带/、版本≥2.2、配合clear-cache与--refresh确保生效。
必须在 Dockerfile 的 RUN 指令里写死镜像源，宿主机的 composer config -g 完全无效。
为什么 composer config -g 在容器里不生效
容器启动时读的是自己环境里的配置，不是宿主机的 ~/.composer/config.json。基础镜像（比如 php:8.1-cli）通常连 /root/.composer 目录都没有，--global 写入会静默失败。你看到的“已配置”，其实是宿主机命令的输出，跟构建过程无关。
- 验证方式：在
RUN里加一句composer config -g repo.packagist，输出必须是完整 JSON，例如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} - 如果输出空、
packagist.org或报错No configuration present，说明没写进去 -
composer.json里写repositories只影响当前项目，create-project和全局命令仍走默认源
RUN composer config -g 怎么写才不失败
三要素缺一不可：参数正确、URL 合规、版本匹配。漏掉任意一个，配置就白写。
- 必须带
-g（即--global），否则只对当前composer命令生效，下一指令就失效 - URL 末尾必须有
/，否则生成的 JSON 格式错误，后续composer install会直接报错 - 先检查版本：
RUN composer --version输出必须 ≥2.2，否则http-max-concurrent-downloads静默无效 - 推荐写法：
RUN composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ && composer config -g http-max-concurrent-downloads 8
并发数设太高反而更慢
http-max-concurrent-downloads 不是越大越好。设到 15 容易触发 file_put_contents(/tmp/): failed to open stream——这不是磁盘满，而是容器 tmpfs 的 inode 耗尽，临时文件竞争导致失败。
- 安全值是
8；CI 环境若仍不稳定，降到6 - 别用已弃用的
parallel-downloads，它在 Composer 2.2+ 里完全无效 - 验证镜像连通性：
RUN curl -I https://mirrors.aliyun.com/composer/packages.json，必须秒回200
多阶段构建中 vendor 缓存失效的隐藏坑
缓存链断一次，每次构建都重下包、重解压、重生成 autoload，CI 动辄多花 4–5 分钟。问题往往不在镜像源，而在 COPY 顺序和中间指令。
-
COPY . /app绝不能出现在COPY composer.json composer.lock ./和RUN composer install之前 - 这两行之间不能插任何指令（比如
RUN chmod、RUN mkdir），否则整个 vendor 层缓存失效 - 必须同时
COPYcomposer.json和composer.lock，缺一不可；只拷composer.json会让 Docker 认为这一层“可能不同”，跳过缓存 - builder 和 final 阶段的 PHP 小版本（如
8.1）、发行版（如bullseye）必须一字不差对齐，否则 classmap 生成逻辑与运行时解析脱节
最容易被忽略的是 WORKDIR 和 --chown：builder 阶段生成的 autoload.php 路径是基于其 WORKDIR 写死的，final 阶段若 WORKDIR 不同或 vendor/ 属主不是运行用户（如 www-data），容器启动就报 Failed opening required 'vendor/autoload.php'。
