验证镜像源packages.json是否同步到位，需检查last-modified响应头和.lastmodified字段是否与当前时间相差≤180秒，而非仅看状态码或文件大小；阿里云等镜像存在1–3分钟固有延迟，超时即不可信。
怎么验证镜像源 packages.json 是否同步到位
看 Last-Modified 头和 lastModified 字段是否接近当前时间，不是看文件大小或状态码是否为 200 就完事。阿里云等主流镜像同步有 1–3 分钟固有延迟，但超过 180 秒就不可信。
实操建议：
- 运行
curl -I https://mirrors.aliyun.com/composer/packages.json，检查响应头中Last-Modified时间是否在当前时间 ±180 秒内 - 再跑
curl -s https://mirrors.aliyun.com/composer/packages.json | jq -r '.lastModified'，和官方源curl -s https://packagist.org/packages.json | jq -r '.lastModified'对比，二者差值必须 ≤180 秒 - 注意：这个
lastModified是全站最后更新时间，不代表所有包都已就绪——它只是元数据同步的“起点信号”，不是终点保证
provider-*.json 文件缺失或哈希不一致怎么办
包查不到、hash mismatch in provider file 报错，90% 出在这里。镜像站可能已同步 packages.json，但某个 p/provider-laravel~10.0.json 还没生成或哈希已失效。
实操建议：
- 先定位目标包对应 provider 文件名：
curl -s https://mirrors.aliyun.com/composer/packages.json | jq -r '.provider-includes | keys[] | select(contains("laravel"))' - 分别对镜像和官方源该文件做哈希比对：
curl -s https://mirrors.aliyun.com/composer/p/provider-laravel~10.0.json | sha256sumvscurl -s https://repo.packagist.org/p/provider-laravel~10.0.json | sha256sum - 若镜像返回 404 或哈希不等，说明该分片未同步完成；此时即使
composer show能列出包名，composer install到具体版本时仍会失败
为什么 verify-checksums --strict 经常“没报错却漏检”
因为这个命令只校验 dist.sha256 非空的包，而中文镜像环境下大量包的该字段为空或已被替换——它不报错，也不警告，只是默默跳过。
实操建议：
- 确认是否启用实验模式：
COMPOSER_EXPERIMENTAL=1 composer verify-checksums --strict，否则--strict不生效 - 检查锁文件里是否有
dist.sha256：jq -r '.packages."monolog/monolog"[] | select(.dist.sha256) | .dist.sha256' composer.lock，为空则该包不会被校验 - 常见空字段原因：包作者只发布 source（git clone）、镜像未同步原始哈希、项目用了
"type": "package"手动配置——这些情况下，verify-checksums什么都不会做
如何用 Merkle Tree 校验单个包是否属于某次快照
你不需要下载全部包，只需要三样东西：leafHash（由 name\0version\0dist.sha256 构造）、公布的 root hash、以及对应位置的 proof 数组。错一个字节，验证即失败。
实操建议：
- 构造叶子节点必须用二进制 digest：
hashlib.sha256(b"monolog/monolog\02.12.0\0a1b2c3").digest()，不能用 hex 字符串 - 叶子数非 2 的幂次时，**重复最后一个叶子补足**（不是填零），这是 Packagist 和
merkletreejs的默认行为 -
proof是兄弟节点哈希值列表，顺序和左右方向必须严格匹配；用tree.verify(proof, leaf, root)前，确保proof是从同一棵树、同一索引生成的——索引偏移 1 位，整个路径就无效
packages.json 可能是新的，但其中声明的每个 provider-includes 文件未必可用；而 verify-checksums 和 composer install 都不会提前告诉你哪几个 provider 缺失，错误只在真正安装那个包时才暴露。
