composer 2.2+ 已废弃 repo.packagist，必须用 repositories.packagist.org 键名并分设 type 和 url（末尾带/），且项目级 repositories 字段会完全覆盖全局配置，需检查、清空并删除 vendor/composer.lock 后验证真实请求。
镜像配置写了，composer install 还是直连 packagist.org —— 不是“没配对”，而是配置被静默忽略或覆盖了。
为什么 composer config -g repo.packagist 没用
Composer 2.2+ 已彻底废弃 repo.packagist 这个键名，写进去也不会读。它只认 repositories.packagist.org，且必须拆成两行设置：
composer config -g repositories.packagist.org.type composercomposer config -g repositories.packagist.org.url https://mirrors.aliyun.com/composer/
漏掉 .type 行，或 url 少了末尾 /，都会导致请求发到错误路径（比如 /p2/xxx.json），返回 404 或 SSL 错误。
项目级 repositories 字段会完全屏蔽全局镜像
只要项目根目录的 composer.json 里有 "repositories" 字段，哪怕内容是空数组 {} 或只关掉了 packagist：{"packagist.org": false}，全局配置就彻底失效。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 检查命令：
grep -A 5 '"repositories"' ./composer.json - 临时清空：
composer config --unset repositories（注意不加-g） - 清完必须删掉
vendor/和composer.lock，否则旧 lock 文件仍按原始源解析
验证镜像是否真在被请求，别信 config --list
composer config -g 显示有值，不代表网络请求走的是这个地址。真实行为得看连接发起点：
- Linux/macOS：
strace -etrace=network composer install 2>&1 | grep 'connect'，看 IP 是否指向国内镜像服务器（如阿里云 114.114.114.114） - 更轻量：
curl -I https://mirrors.aliyun.com/composer/packages.json，必须返回HTTP/2 200；若卡住、301 或返回 HTML 页面（清华源有时会人机验证），说明镜像服务层已异常 - CI 环境（GitHub Actions/GitLab CI）默认不继承本地全局配置，必须在 workflow 中显式执行镜像设置命令
clear-cache 不等于刷新元数据，--refresh 才是关键
composer clear-cache 只删 ZIP 包和旧 packages.json 缓存文件，但不会强制重拉远程元数据——Composer 默认缓存 packages.json 15 分钟，期间仍可能复用过期内容。
- Composer ≥ 2.5：用
composer update --refresh，它丢弃所有已缓存的packages.json，只从当前生效镜像源重新下载 - 如果还卡在
Loading composer repositories，问题大概率不在 Composer 配置，而在 TLS 握手（证书链缺失）、DNS 解析失败或企业防火墙拦截 SNI
真正容易被忽略的点是：镜像 URL 必须带结尾斜杠，https://mirrors.aliyun.com/composer/ ✅，https://mirrors.aliyun.com/composer ❌；还有 Windows 下 Git Bash 可能读错配置路径，改的是 ~/.composer/config.json，实际却加载了 %APPDATA%\Composer\config.json。
