Composer无元数据备份功能，唯一可信依赖快照是composer.lock；有效存档必须组合保存composer.json与composer.lock，或私有包源完整镜像。
Composer 的元数据备份根本不是标准功能
Composer 本身不提供“元数据备份”机制，也没有 backup、archive 或 verify-metadata-backup 这类命令。你看到的所谓“元数据备份”，大概率是以下某一种情况：
— 有人手动复制了 vendor/composer/installed.json 或 composer.lock；
— 第三方脚本导出了 composer show --format=json 结果；
— CI/CD 流程中缓存了 vendor/ 目录或 ~/.composer/cache/；
— 使用了私有仓库（如 Satis、Private Packagist）并误以为其索引是“本地备份”。
验证 composer.lock 是否一致且可复现
composer.lock 才是 Composer 实际依赖状态的唯一可信快照。有效性检查核心是：它能否在干净环境中还原出完全相同的依赖树。
实操建议如下：
- 删掉
vendor/和composer.lock（留一份备份），运行composer install --no-dev；若失败，说明 lock 文件已损坏或来源不可信 - 对比两次安装后的
vendor/composer/installed.json的 SHA256 哈希值（用sha256sum vendor/composer/installed.json），必须完全一致 - 运行
composer show --locked --format=json | jq -S . > locked.json，再对新生成的locked.json和原始备份做diff—— 注意：不同 Composer 版本可能微调字段顺序或添加元信息，建议用jq -S标准化后再比
检查 installed.json 备份是否过期或被篡改
vendor/composer/installed.json 是运行时生成的，内容随 composer install 动态变化，**不能脱离当前 vendor 目录单独验证**。直接拿它当“备份”使用极易出错。
常见陷阱：
- 把旧项目的
installed.json拷到新项目里，执行composer dump-autoload不会恢复包代码，只会报Class not found - 修改过
installed.json中的dist.reference字段试图“回滚版本”，但实际下载行为由composer.lock控制，该字段仅用于调试显示 - 用
composer update --lock更新 lock 后，旧installed.json立即失效 —— 它只反映上一次install的结果，不参与决策
真正需要长期存档时，该存什么
如果目标是灾难恢复或审计合规，有效存档组合只有两个：
-
composer.json+composer.lock（必须一起保存，且 commit 到 Git） - 私有包源的完整镜像（如用
satis build产出的静态 HTML/JSON 包索引，配合所有 tarball 的 SHA256 校验文件）
其他任何“备份 installed.json”“导出 require 列表”“抓取 packagist.org API 快照”的做法，在 Composer 生态中都没有语义保证。最常被忽略的一点是：composer.lock 里的 content-hash 字段，它校验的是 composer.json 内容，而非依赖本身 —— 所以哪怕 lock 文件看起来完整，只要 json 文件被悄悄改过一行，整个还原过程就已不可信。
