最准方式是直接比对官方源和镜像源的p2/vendor/package.json版本列表，因packages.json的lastmodified仅反映全站元数据更新时间，无法体现具体provider分片（如p2/monolog/monolog.json）是否同步完成，而composer实际请求的是这些分片文件。
直接比对 p2/vendor/package.json 的版本列表最准，不是看 packages.json 里有没有这个包，也不是测首页响应快不快。
为什么 packages.json 的 lastModified 不够用
它只表示全站元数据“整体”更新时间，但 Composer 实际请求的是分片文件，比如 p2/monolog/monolog.json。镜像可能已更新 packages.json，却还没生成或同步对应 provider 文件——此时 composer require monolog/monolog:3.6.0 仍会报 Could not find package。
- 阿里云实测中，
packages.json已更新，但provider-monolog~3.6.json滞后 90 秒很常见 - 腾讯云在 Laravel 12 RC 发布初期，
p2/laravel/framework.json延迟可达 4 分钟 - 华为云教育网节点偶发因 CDN 缓存策略，
p2下 dev 分支元数据缺失
怎么用 curl 快速比对两个源的版本列表
选一个你关心的包（比如 monolog/monolog），分别从官方源和镜像源拉取 p2 接口，提取版本键并排序对比：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
curl -s https://packagist.org/p2/monolog/monolog.json | jq -r '.packages."monolog/monolog" | keys[]' | sort | tail -3
curl -s https://mirrors.aliyun.com/composer/p2/monolog/monolog.json | jq -r '.packages."monolog/monolog" | keys[]' | sort | tail -3
- 两组输出必须完全一致（包括大小写、
dev-前缀、3.6.0@dev这类格式） - 若镜像输出缺了最新 tag，说明同步延迟；此时即使
TTFB ，也装不上新版本 - 返回
404或空响应，不是网络问题，是 provider 分片未同步完成
如何确认当前 Composer 真正在用哪个镜像
很多人以为自己配了阿里云，结果 composer update 日志里还是出现 Downloading https://packagist.org/——那根本没生效。
- 查全局配置：
composer config -g repos.packagist.url（注意是repos复数，不是repo） - 查项目级配置：
composer config repos.packagist.url（进项目目录后运行，有输出则优先级更高） - 若任一命令输出为空、
null或仍是https://packagist.org，说明当前走的是官方源 - 项目
composer.json中只要存在"repositories"字段（哪怕值是[]），就会完全屏蔽全局镜像
同步延迟时该等还是该动手
主流镜像同步延迟属正常现象：阿里云通常 ≤ 90 秒，腾讯云高峰 3–5 分钟，华为云偶发更长。这不是配置错误，也不用换源。
- 等：新包发布后，建议等 2–3 分钟再试；CI 中可加
sleep 180避免失败 - 强制刷新元数据：
composer update --refresh（仅 Composer ≥ 2.5 支持） - 手动清缓存（老版本必须）：
rm -rf ~/.composer/cache/repo/https---mirrors.aliyun.com-composer - 别用
composer clear-cache：它不清元数据缓存，对同步延迟完全无效
真正容易被忽略的是：同步延迟 ≠ 网络延迟，测得再快，版本没同步照样装不上。验证必须落到具体 p2 文件，而不是泛泛地“ping 一下”或“看页面更新时间”。
