执行 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，一眼定位问题
