Composer无元数据增量备份功能，所谓“镜像增量备份”实为按需归档provider文件+快照packages.json；需手动抓取并验证存活provider-*.json，仅下载HTTP 200响应的文件。
composer 本身不提供「元数据增量备份」功能，所谓“镜像环境下的增量备份”，本质是对 Composer Metadata V2 协议下 provider 文件的按需归档 + 全量 packages.json 的时效性快照——不是自动同步，而是你主动抓取、验证、存档。
为什么不能直接 backup provider-*.json？
Metadata V2 的 packages.json 里列出了成百上千个 provider-*.json URL（比如 https://mirrors.aliyun.com/composer/p2/monolog/8f1a.json），但这些文件：
- 不随时间递增生成，而是按哈希散列分片，每次全量重建后重新分配
- 镜像站可能滞后：某
provider-8f1a.json在官方源已存在，但阿里云镜像还没拉到，curl -I返回 404 -
composer update会并发请求所有 provider，但失败时只报错、不记录缺失项——你无法从日志反推哪些 provider 缺失
所以“增量备份”不是靠监听变化，而是靠「定期采样 + 验证存活」。
如何手动抓取并验证有效的 provider 文件
目标：拿到当前 packages.json 中所有 provider URL，并仅保存那些返回 200 的 JSON 文件。
实操建议：
- 先获取最新
packages.json：curl -s https://mirrors.aliyun.com/composer/packages.json > packages.json - 用 jq 提取 provider URL 列表（需安装
jq）：jq -r '.providers | keys[]' packages.json | sed 's/^"/https://mirrors.aliyun.com/composer/p2//; s/"$/.json/' > provider-urls.txt - 批量验证并下载存活文件：
while read url; do http_code=$(curl -s -o /dev/null -w "%{http_code}" "$url"); if [ "$http_code" = "200" ]; then echo "$url"; curl -s "$url" -o "providers/$(basename "$url")"; fi; done - 注意目录结构：确保
providers/是空目录，避免覆盖旧文件；每个provider-*.json文件名必须与 URL 路径一致（如provider-8f1a.json）
这个过程不是“自动增量”，而是「一次性的存活快照」。每天执行一次，就相当于一份带时效标记的元数据备份。
packages.json 怎么才算“有效备份”
packages.json 每小时全量生成一次，但它本身不含包内容，只含索引。它的价值取决于两点：
- 是否包含你项目实际用到的 vendor（比如
monolog、symfony）对应的 provider 模板 - 是否与你当前
composer.lock中记录的版本兼容（例如 lock 里用了monolog/monolog:3.0.0，而 packages.json 里没列出该版本的 provider，则 restore 会失败）
因此，备份 packages.json 时务必关联时间戳和对应 commit hash（或 lock 文件 hash）：
cp packages.json packages.json-20260709-1422-$(sha256sum composer.lock | cut -c1-8)
别单独存 packages.json —— 它脱离上下文就是一张废纸。
镜像滞后导致的恢复失败怎么提前发现
最常被忽略的点：你以为备份了所有 provider，结果在离线恢复时 composer install 报 Could not find package monolog/monolog。
这不是 lock 文件问题，而是 provider 缺失。排查步骤：
- 查
composer.lock里monolog/monolog的distURL 或sourcetype，确认它属于哪个 vendor 分片 - 用
php -r "echo md5('monolog') . "\n";"得到前两位哈希（如8f），再检查本地是否有providers/provider-8f*.json - 若无，说明备份时该 provider 在镜像上就是 404；需回退到更早的
packages.json快照，或换其他镜像源重试
真正可靠的备份，不是文件数量多，而是能闭环验证：有 lock → 能定位 provider → 该 provider 存在且含目标包版本 → 可成功 install。
这中间任何一环断掉，备份就只是心理安慰。
