容器里 composer 卡在“loading composer repositories”主因是未切国内镜像源、dns 缓存解析异常、缓存目录未挂载及 vendor 写入受阻；需执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 并设 http-max-concurrent-downloads=8、挂载 ~/.composer-cache、禁用 autoload 生成。
容器里 Composer 卡在 Loading composer repositories 怎么办
这不是 DNS 解析慢，是 PHP 的 cURL 复用 DNS 缓存，把 mirrors.aliyun.com 解析到了海外 IP；更关键的是 Composer 2.2+ 默认硬编码直连 packagist.org，根本连不上。容器没配镜像源，等于裸奔。
必须执行：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意末尾斜杠不能少）
- 验证是否生效：
composer config -g repo.packagist输出必须是完整 JSON，如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} - 别信宿主机的
~/.composer/config.json会透传进容器——它不会 - CI 环境若以非 root 用户运行（如
www-data），需确认HOME环境变量指向其家目录，否则配置写错位置
为什么配了双镜像，composer install 还卡 30 秒
因为 Composer 默认对每个源单独等待 30 秒超时，才尝试下一个。网络卡顿、TLS 握手慢、IPv6 fallback 延迟都会拖住这个计时器。
- 临时验证是否走镜像：加
-vvv参数，看日志里实际请求的域名（搜索Downloading行） - 全局延长超时：
composer config -g http.timeout 600 - 更治本：加环境变量
COMPOSER_IPV4=1强制走 IPv4，绕过 IPv6 延迟 - 别设
http-max-concurrent-downloads> 8，设 15 容易触发file_put_contents(/tmp/): failed to open stream—— 不是磁盘满，是容器 tmpfs inode 不够
composer.json 里写死多个 repositories 的典型错误
常见报错：Could not load package xxx in http://packagist.org，但该包明明在阿里云镜像里存在。
- 国内镜像必须用
"type": "composer"，且 URL 末尾带/（如"url": "https://mirrors.aliyun.com/composer/"） -
"packagist.org": false必须写在composer.json根节点，不能塞进repositories数组里，否则无效 - 不要混用
type: "composer"和type: "package"在同一repositories列表里——后者会被忽略 - 顺序即优先级：最快镜像（如阿里云）必须放第一位，官方源放最后；Composer 不轮询、不故障转移，只取第一个能返回有效元数据的源
Docker 构建中 vendor 层缓存失效的三个致命操作
缓存链一断，每次构建都重下包、重解压、重生成 autoload，CI 动辄 3–5 分钟。
-
COPY . /app放在COPY composer.json composer.lock ./前面——代码一改，整个vendor层重建 - 在
COPY composer.json composer.lock ./和RUN composer install之间插了RUN chmod或RUN mkdir——破坏缓存链 - 没固定
COMPOSER_CACHE_DIR，又没启用 BuildKit 缓存挂载，导致每次下载全量包 - 正确顺序只有一种：
COPY composer.json composer.lock ./→RUN composer install --no-dev --optimize-autoloader --classmap-authoritative --no-scripts
高可用不是堆镜像，而是控制加载顺序、规避 DNS/IPv6 延迟、切断缓存污染链——这些点漏掉任何一个，容器里的 Composer 就永远“看起来在动，其实卡死了”。
