验证配置是否生效必须执行composer config -g repo.packagist并确认输出为{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}这类完整json；空、null、报错或仍显示packagist.org均说明未写入成功，常见原因包括漏-g、键名多s、url缺/或被项目级repositories覆盖。
运行 composer config -g repo.packagist 看输出是否为完整 JSON
这是最直接的验证动作，但很多人只执行命令就以为成功了。必须确认输出是形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 的完整 JSON 对象。如果返回空、null、Key "repo.packagist" does not exist 或者仍是 "url": "https://packagist.org"，说明配置根本没写进去——常见原因是漏 -g、键名写成 repos.packagist（多一个 s）、URL 缺末尾 /，或 Composer 版本 ≥2.2 时该键名已被废弃。
加 -vvv 观察真实请求域名
配置可能“存在”，但不“生效”。唯一能确认实际走哪个源的方式，是让 Composer 发一次真实请求并打印日志：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer install -vvv 2>&1 | grep "Downloading"（Linux/macOS）或composer install -vvv | findstr "Downloading"（Windows） - 重点看日志里出现的域名：必须是
mirrors.aliyun.com、mirrors.tuna.tsinghua.edu.cn这类镜像站，而不是packagist.org - 注意：仅靠
composer config输出无法反映项目级repositories字段的覆盖行为，-vvv日志才是真相
用 curl -I 测试镜像地址是否可访问
配置对了，不代表镜像服务本身可用。Composer 不会主动告诉你 404 或超时，而是静默 fallback 到官方源：
- 执行
curl -I https://mirrors.aliyun.com/composer/packages.json - 必须返回
HTTP/2 200或HTTP/1.1 200 OK；若返回404，大概率是 URL 少了末尾/（比如写成https://mirrors.aliyun.com/composer） - 若返回
Could not resolve host，检查 DNS 或网络策略；若卡住几秒后失败，可能是 TLS 握手问题（旧版 OpenSSL 或 cURL 不支持 SNI）
检查项目级 repositories 是否覆盖全局设置
即使全局配置正确，只要项目根目录的 composer.json 里有 "repositories" 字段，就会无条件屏蔽全局镜像：
- 运行
composer config repositories，查看输出中packagist.org对应的url是什么 - 用
grep -A5 '"repositories"' composer.json检查是否硬编码了无效源（如已下线的https://packagist.phpcomposer.com） - 临时禁用项目配置验证：
composer config --unset repositories（注意没有-g），再试composer install -vvv
repositories 覆盖和 -vvv 日志验证这一步。
