只备份vendor目录没用，因为vendor是构建产物而非源配置；真正需保护的是composer.json和composer.lock——它们声明依赖意图、锁定精确版本，确保可重现安装与安全回滚。
升级前不备份 composer.json 和 composer.lock，等于在没系安全带的情况下踩油门——出问题时根本没法回滚。
为什么只备份 vendor 目录没用？
vendor 是构建产物，不是源配置。Composer 升级（尤其是 major 版本如 2.x → 3.x）可能改变依赖解析逻辑、锁文件格式或插件 ABI，导致 composer install 在旧 vendor 上直接失败，或装出不一致的包树。真正需要保护的是声明意图的元数据文件。
常见错误现象：composer update 后 vendor/autoload.php 报错找不到类、某些包版本跳变、composer.lock 被重写且无法 git revert 到干净状态。
- 必须备份
composer.json和composer.lock两个文件（文本可 diff，体积小，git 原生支持） - 如果项目用了自定义
repositories或config（如fxp-asset-plugin配置），也要备份composer.json的完整内容 - 不要依赖
git stash临时存，它可能被误删；应git commit -m "backup pre-composer-upgrade"并推送到远端
如何验证备份是否有效？
备份不是“存完就完”，得能快速验证还原路径是否通。关键动作是模拟一次干净重建：
- 删掉
vendor/和composer.lock（保留备份好的原始composer.lock） - 运行
composer install --no-scripts --no-plugins（跳过可能出错的脚本和插件） - 检查输出是否与备份前
composer show的包列表、版本号完全一致 - 若失败，说明
composer.lock已损坏或被非官方源污染，需从备份中手动恢复
私有源场景下容易漏掉的关键点
如果你的 composer.json 启用了私有仓库（比如 "type": "composer", "url": "https://your.repo.com"），备份时要注意：
- 私有源的
packages.json元数据本身不可靠——它可能随时间变动，甚至被清理。所以不能只信线上源，必须把当时生效的composer.lock里记录的 exact dist URLs 和 shasum 一起备份 - 若用了
{"packagist.org": false}，确保备份的composer.json里该配置项存在且格式正确（必须是独立对象，不能合并进前一个repositories条目） - 升级 Composer 后首次运行
composer update，会重新抓取所有仓库的packages.json；若私有源此时不可达，会导致元数据缺失、降级到 packagist —— 这种静默 fallback 很难察觉，但后果严重
最常被忽略的其实是时间窗口：Composer 升级命令（如 composer self-update）执行后，新二进制会立刻接管后续所有操作。一旦 composer update 开始写 composer.lock，旧版锁文件就再无机会自动还原——所以备份动作必须在 self-update 之前完成，且不能依赖“等报错再补救”。
