Composer 不支持 vendor 自动备份，因其视 vendor 为可重建临时产物；推荐用 composer.lock 版本控制、容器化构建或硬链接快照（cp -al）实现轻量追溯。
Composer 本身不支持自动备份 vendor 目录，也没有内置的 --backup 或类似开关；任何声称“开箱即用”的方案都不可信。
为什么 Composer 不提供 vendor 自动备份功能
Composer 的设计哲学是将 vendor 视为可完全重建的临时产物——只要 composer.lock 存在，composer install 就能还原一致状态。备份 vendor 不仅冗余（体积大、校验难），还可能掩盖依赖一致性问题。
常见误操作包括：手动复制整个 vendor 后修改了其中某包代码，却忘了清理或提交 patch，导致下次 update 覆盖后行为突变，排查困难。
-
vendor通常含数万文件，压缩/解压耗时且易中断 - Git 不适合跟踪二进制或频繁变更的依赖目录
- 备份若未排除
.git、node_modules等子目录，会引入嵌套冲突
用 post-update-cmd 脚本实现轻量级快照
可在 composer.json 中注册钩子，在 composer update 成功后，仅对变更过的包做符号链接快照（非全量拷贝），兼顾速度与可追溯性：
{
"scripts": {
"post-update-cmd": [
"if [ -f 'composer.lock' ]; then mkdir -p vendor-snapshots; fi",
"if [ -f 'composer.lock' ]; then TIMESTAMP=$(date -u +%Y%m%d-%H%M%S); cp -al vendor \"vendor-snapshots/vendor-$TIMESTAMP\"; fi"
]
}
}
说明：
-
cp -al是关键：硬链接克隆，几乎零磁盘开销，且保留原始文件权限和时间戳 - 仅当
composer.lock存在才执行，避免初始化时误触发 - 快照名含 UTC 时间戳，避免并发更新覆盖（本地时区可能导致重名）
- 不建议用
rsync -a --delete：它会删除目标中多余文件，但硬链接结构下可能误删源文件引用
更安全的替代方案：用 Git 管理 lock 文件 + 容器化构建
真正需要“回滚到旧依赖状态”时，应依赖 composer.lock 版本控制，而非 vendor 备份：
- 每次
composer update后，必须git add composer.lock && git commit -m "update deps" - CI 流水线中用
composer install --no-dev构建，确保环境纯净 - 本地开发若需快速切依赖版本，直接
git checkout <old-commit> && composer install</old-commit>，比恢复vendor快且确定 - 如确需离线部署，用
composer install --prefer-dist --no-interaction配合已缓存的~/.composer/cache
硬链接快照虽快，但要注意：它只在同文件系统内有效；跨磁盘移动或打包时会退化为普通复制，体积暴增。真要归档，优先导出 composer.lock 和自定义 patches。
