答案是composer本地缓存了过期的packages.json（如指向已下线的https://packagist.phpcomposer.com），导致请求失败；应运行composer config --list | grep repositories.packagist.org.url确认实际镜像url，用composer update --refresh（≥2.5）强制刷新元数据，或手动删除对应repo缓存目录。
直接结论：不是镜像挂了，也不是包没发布，而是 Composer 本地缓存了过期的 packages.json 路径（比如指向已下线的 https://packagist.phpcomposer.com），导致它反复请求一个根本不存在的地址——所有“版本找不到”“404”“connection refused”都源于此。
怎么确认当前用的是哪个镜像 URL
别猜，用命令看实际生效的源：
- 运行
composer config --list | grep repositories.packagist.org.url，输出必须是类似https://mirrors.aliyun.com/composer/（注意结尾斜杠） - 如果输出为空、是
http://开头、或仍是https://repo.packagist.org，说明当前没走任何有效镜像 - 项目根目录若有
composer.json且含"repositories"字段，它会**完全屏蔽**全局配置，哪怕你config -g配得再对也无效
为什么 composer clear-cache 后还是旧路径
composer clear-cache 清的是整个缓存目录，但下次 update 会立刻重建并复用旧的 packages.json 缓存——它根本不校验 URL 是否还有效。真正卡住的是元数据缓存，不是 ZIP 包。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- Composer 默认复用本地缓存的
packages.json，15 分钟内不过期，哪怕镜像站已同步新版本，它也不发请求 - 正确做法是强制刷新元数据：
composer update --refresh（≥2.5 版本），它只丢弃packages.json和provider-*.json，不碰 ZIP 缓存 - 老版本 Composer 只能手动删：
rm -rf $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer
CI 环境里镜像配置总不生效
GitHub Actions / GitLab CI 默认不继承你本地的全局镜像配置，composer config -g 写的设置在 CI 中根本不存在。
- 必须在 workflow 中显式执行两行设置：
composer config -g repositories.packagist.org.type composer和composer config -g repositories.packagist.org.url https://mirrors.aliyun.com/composer/（缺一不可，URL 末尾必须带/） - CI 日志里要 grep 到
https://mirrors.aliyun.com/composer/才算真走镜像；否则就是静默 fallback 到官方源 - CI 缓存 key 必须包含 lock 文件哈希：
key: ${{ runner.os }}-composer-${{ hashFiles('**/composer.lock') }}，否则旧 provider 地址会被固化
最常被忽略的点：项目级 composer.json 里的 "repositories" 字段哪怕写成空数组 {} 或 {"packagist.org": false}，也会让全局镜像配置彻底失效——这不是 bug，是 Composer 的明确设计，但没人提醒你。
