根本原因是Composer默认复用15分钟内不过期的本地packages.json元数据缓存，不发起远程请求；解决需用composer update --refresh（≥2.5）强制刷新，或手动删除对应repo缓存子目录。
composer update 为什么拉不到新版本，不是网络问题而是缓存策略
根本原因不是镜像同步慢，而是 Composer 默认复用本地 packages.json 快照——它存在 ~/.composer/cache/repo/https---mirrors-aliyun-com-composer/packages.json 这类路径下，15 分钟内绝不重拉。哪怕镜像站已上线 v3.6.0，你执行 composer update monolog/monolog 仍会返回 Nothing to install or update。
- 验证现象：运行
composer show monolog/monolog显示3.5.0，但打开https://mirrors.aliyun.com/composer/p2/monolog/monolog.json能看到3.6.0的版本记录 - 确认是否真走镜像：执行
composer config -g repo.packagist.url，输出必须是https://mirrors.aliyun.com/composer/——HTTP 地址会被静默拦截 - 检查是否被项目级覆盖：运行
composer config --list | grep repositories，若repositories.packagist.url不是你设的镜像地址，说明composer.json里写了"repositories"字段，得删或重写
composer update --refresh 到底做了什么
composer update --refresh（仅 Composer ≥ 2.5 支持）专为元数据延迟设计：它只删除 cache/repo/ 下的 packages.json 和 provider-*.json，然后从当前生效镜像源重新下载最新索引，不重下 ZIP 包，也不动 vendor/ 或 composer.lock。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 执行后立刻跑
composer update vendor/package就能识别镜像站刚同步的新版本 - 老版本（≤ 2.4）不支持该参数，会报错
Unrecognized option: --refresh - Windows 用户注意路径转义：
rd /s /q %APPDATA%\Composer\Cache\repo\https---mirrors-aliyun-com-composer
镜像源本身导致的元数据不一致风险
国内镜像必然存在 5–30 分钟同步延迟，跨国团队若分别使用阿里云北京节点和腾讯云广州节点，同一时刻查到的可用版本就可能不同。更隐蔽的是：某成员本地用了项目级 "repositories" 指向已停用的旧镜像（如 https://packagist.phpcomposer.com），composer install 会静默 fallback 到官方源，而其他人走的是正常镜像——结果就是 vendor/ 目录里类名对得上，但行为不一致。
- 验证元数据时效性：对比
curl -s https://mirrors.aliyun.com/composer/packages.json | jq '.lastModified'和curl -s https://packagist.org/packages.json | jq '.lastModified' - 私有包不受镜像影响，但若
composer.lock中dist.url指向 GitHub Release，而 GitHub 在某些地区访问不稳定，也会造成“同一命令在不同国家失败” -
composer clear-cache清的是 ZIP 包和 provider 缓存，不碰packages.json快照，所以不能解决元数据滞后问题
Metadata V2 协议下镜像滞后的真实表现
Composer Metadata V2 把元数据拆成 packages.json（全量索引）+ 大量 provider-*.json（按哈希分片的包列表）。客户端每次 update 都会并发拉取所有 provider-*.json，如果镜像站某片没同步，你就卡在那个 404 上——进度条停住、命令无响应，不是慢，是直接阻塞。
-
packages.json每小时或每天全量生成一次，含所有 vendor 的 provider 模板（如"https://mirrors.aliyun.com/composer/p2/{vendor}/{hash}.json"） - 每个
provider-*.json对应一个 vendor 下若干包的版本映射，体积小、可独立更新 - Composer 不缓存
provider-*.json——每次update都重新拉，所以镜像延迟直接影响命令耗时
