答案是“手动触发镜像同步”不存在，实际是强制重拉本地元数据：用composer update --refresh（≥2.5）精准删除packages.json和provider-*.json后从当前生效镜像重载索引，不触碰ZIP缓存。
“手动触发镜像同步”根本不存在
Composer 客户端没有、也不可能提供任何命令去“通知镜像站立刻拉取最新数据”。镜像站的同步是服务端行为（比如阿里云每15分钟轮询一次 packagist.org），你本地执行 composer 命令，永远影响不了它的调度逻辑。所谓“手动同步”，实际是你控制本地如何重新获取并信任最新元数据，而不是让镜像站加班。
确认当前生效的镜像地址是否正确
很多人卡在第一步：以为自己配了阿里云镜像，其实被项目级配置覆盖了，或者压根没生效。
- 查全局镜像：
composer config -g repo.packagist—— 输出应为https://mirrors.aliyun.com/composer/这类地址（注意是单数repo.packagist，不是repos） - 查项目级镜像（更优先）：
composer config repo.packagist（不带-g），如果输出不同或报错“Not found”，说明项目composer.json里写了"repositories"字段，它会完全屏蔽全局配置 -
composer diag不验证镜像！它只连https://packagist.org，报错 ≠ 镜像挂了；要测镜像连通性，直接用：curl -I https://mirrors.aliyun.com/composer/packages.json，必须看到HTTP/2 200
强制重拉元数据：用 composer update --refresh
这是 Composer ≥ 2.5 提供的精准解法，也是最推荐的操作。它不做无谓清理，只丢弃决定“包是否存在”的关键元数据文件，再从你当前配置的镜像源重新下载。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 它删除的是
packages.json和provider-*.json，这些文件控制包列表、版本可用性、autoload 映射等，缓存在~/.composer/cache/repo/https---mirrors-aliyun-com-composer/这类路径下 - 它不删 ZIP 包缓存，所以不会重复下载几十 MB 的 dist 包
- 加
--no-cache -v可看到真实请求 URL，确认是否命中你配的镜像（例如日志里出现GET https://mirrors.aliyun.com/composer/p2/symfony/console.json） - 老版本 Composer（--refresh，只能手动进缓存目录删对应
repo/https---*子目录，但容易删错路径
清缓存 ≠ 刷新元数据，别白忙活
composer clear-cache 主要清 ZIP 包和部分临时 JSON，对 packages.json 和 provider-*.json 几乎无效。这些元数据文件独立存在、命名规则特殊，且路径由镜像 URL 转义生成（比如 https---mirrors-aliyun-com-composer），删错目录等于没操作。
- 先定位缓存位置：
composer config --global cache-dir - 再进 repo 子目录看真实结构：
ls -d $(composer config --global cache-dir)/repo/https---* - Windows 用户路径类似：
%APPDATA%\Composer\cache\repo\https---mirrors-aliyun-com-composer - 如果项目用了腾讯云内网镜像（
mirrors.tencentyun.com），但删的是mirrors.cloud.tencent.com对应的目录，就毫无意义
真正复杂的地方在于：元数据刷新和包下载是两层逻辑，而镜像之间本身就有延迟差——阿里云每15分钟同步，华为云每2小时。当你发现某个新版本在阿里云镜像里查不到，别硬等，换源比等更可靠；更别试图“手动触发”，那只是个幻觉。
