Composer本身不提供元数据增量备份功能，所谓“增量备份”实为借助Git等VCS对composer.lock文件进行版本化管理与diff识别，核心是通过git diff或jq解析lock文件变更来实现依赖变更的精准追溯。
composer 本身不提供元数据增量备份功能，也没有内置的 diff 或 backup 命令。所谓“Composer 元数据增量备份”，实际是开发者对 composer.lock 文件做版本化管理后，借助 Git 等工具实现的差异识别与归档策略。核心判断：你不是在用 Composer 做备份，而是在用 Git（或其他 VCS）备份 Composer 的输出结果。
为什么直接 diff composer.lock 就是有效增量识别
composer.lock 是锁定依赖树的权威快照，包含所有包名、版本、哈希、require 嵌套关系及平台配置。只要它被提交进 Git，每次 composer install 或 composer update 后的变更都会反映为该文件的文本差异。
- 常见错误现象：有人试图用 composer show --outdated 或解析 vendor/ 目录来判断“哪些包变了”，这不可靠——vendor/ 可能被手动修改、未提交、或受 platform 配置影响
- 正确做法是只信任 composer.lock 的 Git diff 结果
- 示例命令：git diff HEAD~1 -- composer.lock，能清晰看到新增、删除、降级、哈希变更等全部变化
如何避免 lock 文件 diff 失效的典型坑
- composer.lock 必须提交进仓库，且不能被 .gitignore 排除；否则“增量”无从谈起
- 不要手动编辑 composer.lock —— 它是自动生成文件，手工改会导致哈希校验失败，composer install 报错 Invalid argument supplied for foreach() 或 Package is not installed
- 多人协作时，若同时运行 composer update，可能因排序或时间戳字段（如 time 字段）导致无意义 diff；建议统一使用 composer update --no-scripts --no-plugins 并禁用 sort-packages 配置项（除非显式开启）
- platform 配置变动（如 PHP 版本切换）会触发整个 lock 文件重写，看似“全量变更”，实则只是元数据适配——需结合 git blame composer.lock 判断是否真有依赖变更
用脚本自动化识别真实依赖变更
单纯看 diff 文本效率低，可用简单 shell 提取关键变更行：
- git diff -U0 HEAD~1 -- composer.lock | grep '^+' | grep -E '"name":|"[a-z]+":.*[0-9]+'（粗筛新增/修改的包行）
- 更可靠的是用 jq 解析前后两个 lock 文件：
jq -r '.packages[] | "\(.name)@\(.version)"' composer.lock > current.txt jq -r '.packages[] | "\(.name)@\(.version)"' composer.lock~1 > prev.txt diff prev.txt current.txt
- 注意：此方法要求 composer.lock 中的 packages 和 packages-dev 分开处理，否则会漏掉 dev-only 依赖
真正容易被忽略的点在于：增量备份的价值不在“备份动作”，而在“变更可追溯”。一旦 composer.lock 进了 Git，每次 git bisect 都能准确定位哪个 commit 引入了某次依赖升级或安全补丁——这才是工程中真正需要的“增量”。
