Composer镜像配置生效与否不能只看composer config -g repo.packagist输出，必须通过composer diagnose查看“Repo packagist.org:”行或composer require -vvv | grep "GET https"确认实际请求域名，同时清除缓存、检查项目级repositories覆盖及用户权限。
composer config -g repo.packagist 输出不是最终依据
它只告诉你“你写进了什么”，不反映实际运行时读取的是哪个源。常见误判是看到输出了 https://mirrors.aliyun.com/composer/ 就以为配成功了，结果 composer install 还是卡在 Loading composer repositories...。真正起作用的是 Composer 在解析依赖时发起的 HTTP 请求目标。
必须用 -vvv 日志确认真实请求地址
执行一次带详细日志的真实操作，才能验证是否真走镜像：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer clear-cache—— 缓存不清理，旧 packages.json 仍可能被复用 -
composer require monolog/monolog -vvv 2>&1 | grep "GET https"—— 关键看日志里出现的是mirrors.aliyun.com还是packagist.org - 若看到
GET https://packagist.org/packages.json或GET https://repo.packagist.org/packages.json，说明镜像没生效，大概率是项目级repositories字段覆盖了全局配置
composer diagnose 的 “Repo” 行更可信
composer diagnose 会主动检查当前生效的仓库配置，比 config -g 更接近运行时行为：
- 输出中
Repo packagist.org:后面显示的 URL 才是 Composer 实际准备连接的目标 - 如果这里仍是
https://packagist.org，而你又确认config -g repo.packagist输出了镜像地址，那基本可以断定：项目根目录的composer.json里定义了repositories字段，且它优先级更高 - 此时进项目目录执行
composer config repo.packagist，若有输出就坐实了覆盖；若提示Key "repo.packagist" does not exist，才轮到读全局
Alpine 或多阶段构建中容易漏掉用户权限
Docker 场景下，即使 composer config -g 成功写入，final 阶段也可能读不到：
- builder 阶段用
RUN composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，默认写入/root/.composer/config.json - final 阶段若以
www-data用户运行，它不会去读/root/下的配置 - 解决方法是显式切换用户写入：
RUN su www-data -c "composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/" - 另外，Alpine 镜像缺 CA 证书会导致 HTTPS 请求失败，必须加
RUN apk add --no-cache ca-certificates
clear-cache 漏了、repositories 字段存在、或用户身份不一致，都会让配置形同虚设。 
