根本原因是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 Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（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 都重新拉，所以镜像延迟直接影响命令耗时

真正麻烦的不是换源本身，而是元数据缓存与镜像同步节奏之间的错位——它既不会报错，也不会提示，只会安静地给你一个“过期但合法”的依赖视图。