执行 composer clear-cache 不管用，因其仅删除 ZIP 包和 provider 缓存，而 packages.json 元数据缓存（默认 15 分钟）未失效时仍复用旧地址；正确解法是 composer update --refresh（≥2.5）或手动删除对应 repo 子目录（≤2.4），并验证镜像配置生效及真实请求命中镜像域名。

为什么清 composer clear-cache 不管用

执行 composer clear-cache 只删 ZIP 包和 provider 缓存，但 packages.json 元数据缓存会立刻重建并复用旧内容——你看到的“卡在 Loading composer repositories”，八成是它在读本地缓存的旧地址，根本没发请求到镜像站。

• 缓存路径里 ~/.composer/cache/repo/https---mirrors-aliyun-com-composer/packages.json 文件存在且未过期（默认 15 分钟），Composer 就跳过网络请求
• clear-cache 后跑 composer update，日志里仍显示 Downloading https://packagist.org/...？说明元数据根本没刷新
• 镜像 URL 写错（比如少末尾 /）、键名写成 repos.packagist（多一个 s），都会导致配置静默失效，clear-cache 也救不了

composer update --refresh 是唯一精准解法（≥2.5）

它只丢弃 packages.json 和 provider-*.json，不碰已下载的 ZIP 包，快且安全。但必须确认两点才生效：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 先跑 composer config -g repo.packagist，输出必须是你配的镜像 URL（如 https://mirrors.aliyun.com/composer/），结尾斜杠不能少
• 再跑 composer config --list | grep repositories.packagist.url，如果为空，说明项目级 composer.json 的 repositories 字段劫持了全局配置，得先处理那里
• 执行后立刻跟 composer update vendor/package-name，新版本就能被识别出来

老版本 Composer（≤2.4）只能手动删缓存子目录

不支持 --refresh，硬删对应镜像的元数据缓存目录是唯一办法：

• 查缓存根目录：composer config --global cache-dir
• 进 repo/ 子目录，找匹配镜像 URL 的文件夹（如 https---mirrors-aliyun-com-composer）
• 执行：rm -rf $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer
• 别删整个 repo/ 目录——其他镜像或私有源的缓存也会跟着丢

换源后还卡？先验证是否真走镜像

光看 config 输出没用，得看到真实请求打到镜像域名才算数：

• 实测命令：composer show monolog/monolog -vvv 2>&1 | grep "Downloading"
• 日志里必须出现 mirrors.aliyun.com 或 mirrors.tuna.tsinghua.edu.cn 等镜像域名
• 如果看到 packagist.org 或 github.com，说明要么配置没生效，要么某个包硬编码了原始 dist URL（比如私有包写死 GitHub 地址）
• 临时调试加 --no-cache -v，终端会直接打印真实请求 URL，一眼定位问题

缓存重置不是“删干净就完事”，关键在于让 Composer 主动发起新请求——而它只在元数据缓存失效时才这么做。最容易被忽略的是：你删了缓存，却没确认配置是否真正生效，也没验证请求是否真的打到了镜像站。