镜像源“同步慢”实为本地缓存或配置问题：先用composer config -g repo.packagist验证全局配置，再检查项目级repositories是否覆盖；接着curl和浏览器双验证镜像连通性与数据新鲜度；最后用composer update --refresh强制刷新元数据缓存。
镜像源“同步慢”基本是假象，真正卡住你的从来不是镜像站，而是本地元数据缓存没刷新、配置没生效、或项目级设置悄悄覆盖了全局配置。
确认当前生效的镜像地址，别信直觉
很多人改完配置就跑 composer update，结果日志里全是 packagist.org，却以为是镜像慢。最准的方式只有一条命令：
- 运行
composer config -g repo.packagist（注意是单数repo，不是repos） - 输出必须是完整 JSON，例如
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} - 如果为空、
null、报Key not found，或者返回的是https://packagist.org，说明根本没配成功 - 若项目根目录有
composer.json且含"repositories"字段，它会完全屏蔽全局配置；此时应查composer config repo.packagist（不带-g）
验证镜像是否真通、真新，别只看命令返回
配置对 ≠ 能用。必须手动验证两点：连得上、数据新。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 用
curl -I https://mirrors.aliyun.com/composer/packages.json看是否返回HTTP/2 200；403/404/超时都说明不可用 - 打开浏览器，对比官网和镜像站同包地址，例如：
— 官网：https://packagist.org/packages/topthink/framework
— 镜像：https://mirrors.aliyun.com/composer/p/topthink/framework.json
看版本号是否一致 - 若镜像返回 404，但官网已有新版，说明该镜像同步卡住（超 30 分钟未更新属异常），不是你本地问题
强制刷新元数据，不是 clear-cache 就完事
composer clear-cache 只删 ZIP 包和部分 provider 缓存，对决定“有没有这个包”的 packages.json 和 provider-*.json 几乎无效——这些文件被 Composer 默认复用 15 分钟，哪怕镜像已更新也不会重拉。
- Composer ≥ 2.5：直接用
composer update --refresh，它丢弃所有缓存的元数据文件，强制从当前配置镜像源重拉最新索引，但保留已下载的 ZIP 包 - Composer rm -rf $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer
- 临时调试加
--no-cache -v，看终端输出的真实请求 URL 是否命中你配的镜像地址
换源比等更可靠，但得选对场景
不同镜像站元数据不一致时，硬等不如换源。阿里云通常最快（5 分钟内同步），中科大镜像在某些 provider 文件缺失时更全，腾讯云适合华南用户。
- 切阿里云（推荐）：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（末尾/不可省） - 临时切中科大（排查 provider 缺失）：
composer config -g repo.packagist composer https://mirrors.ustc.edu.cn/composer/ - CI 或 Docker 构建中避免污染配置，用
COMPOSER_REPO_PACKAGIST=https://mirrors.aliyun.com/composer/ composer install --prefer-dist - 私有包未同步到镜像？需单独在
repositories中声明，镜像不代理这类源
最常被忽略的一点：镜像只加速元数据和 dist 包下载，不解决依赖解析本身卡顿。如果 composer update 卡在 “Resolving dependencies”，大概率是 composer.json 里 PHP 版本约束太松（如 "php": "^7.4 || ^8.0"）或依赖冲突严重，这时候换十个镜像也没用。
