根本原因是命令未同时满足三个硬性条件：键名必须为单数repo.packagist、type值必须显式写composer、url必须https且末尾带/；任一不符即静默回退官方源，且不报错。
Alpine镜像里composer config -g 为什么总不生效
根本原因不是网络差，是命令写错三个硬性条件，Composer 就静默 fallback 到 https://packagist.org，且不报错、不提示。
-
repo.packagist键名必须一字不差：写成repos.packagist、repository.packagist或mirror全部无效 - 中间的
composer是强制type值，小写，不可省略——漏掉它，配置等于没写 - URL 必须是 HTTPS 且末尾带
/：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会拼出/composerpackages.json，返回 404）
验证是否真写进去了？别信“命令没报错”，运行：composer config -g repo.packagist。输出必须是完整 JSON 对象，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；空、null、或只返回 URL 字符串，都说明失败。
Alpine 镜像必须先装 ca-certificates 才能走 HTTPS 镜像
Alpine 默认不带证书包，composer install 会卡在 TLS 握手阶段，报 SSL certificate problem: unable to get local issuer certificate，看起来像网络超时，其实是证书链验证失败。
- 必须在第一条
RUN指令中就执行：apk add --no-cache ca-certificates - 如果基础镜像还缺
curl（比如某些精简版php:alpine），得顺带补上：apk add --no-cache ca-certificates curl - 这条命令不能和
composer config合并在同一行 ——apk安装后需重新加载证书缓存，单独 RUN 更稳妥
多阶段构建中 Alpine 的 PHP 版本与路径一致性
builder 阶段用 php:8.3-cli-alpine，final 阶段却用 php:8.3-fpm-alpine 看似合理，但实际可能因 musl libc 版本或扩展路径差异，导致 vendor/autoload.php 加载失败或 classmap 错乱。
- builder 和 final 镜像的发行版、PHP 小版本、musl 版本必须一致，推荐统一用
php:8.3-cli-alpine3.20+php:8.3-fpm-alpine3.20 - 避免混用
alpine和debian变体，否则opcache.preload或extension_dir路径不匹配 - final 阶段若以
www-data用户运行，composer config -g写入的/root/.composer/config.json不会被读取 —— 此时应改用项目级配置（见下一点）
项目级配置比全局配置更可靠，尤其在 CI 和非 root 场景
只要项目根目录的 composer.json 里有 "repositories" 字段（哪怕只是空数组 []），全局配置就完全被跳过 —— 不是优先级低，是硬编码绕过，且无任何提示。
- 进项目根目录后执行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不带-g） - 这条命令会向
composer.json的"repositories"数组首位追加镜像项，不覆盖已有私有源 - 切勿手动编辑 JSON —— 一个逗号错位就触发
JSON decode error，composer install直接中断 - 改完必须删掉
vendor/和composer.lock，再跑composer install，否则旧 lock 文件仍按 packagist.org 的 dist URL 和 hash 下载，镜像站可能已下线该旧版本
最容易被忽略的是：项目级 repositories 字段一旦存在，全局配置彻底失效，连验证命令 composer config -g repo.packagist 都看不出问题 —— 因为它确实写进去了，只是根本没机会被读到。
