Composer不管理数据库或文件备份，需用composer.lock固化依赖并配合外部备份；私有包离线部署应使用composer archive打包vendor；数据库与vendor备份须时间对齐以避免RPO风险。
Composer 本身不管理数据库或文件备份，所谓“Composer 备份脚本”是常见误解——你真正需要的，是针对 composer.json 和 vendor/ 目录的依赖状态固化方案，配合外部数据库/文件备份一起用，才能防丢。
为什么不能只靠 composer install 恢复？
看似只要保留 composer.json 就能重装依赖，但实际有三个关键风险点：
-
composer.lock缺失或过期时，composer install会按composer.json最新兼容版本拉取，可能引入破坏性更新（比如 Laravel 从 v10 升到 v11） - 某些私有包、已下线的 tag 或被作者删库的 package，
packagist.org上已不可获取，composer install直接失败 -
vendor/中部分扩展（如ext-redis）依赖系统级组件，环境不一致时即使装上也运行报错
composer.lock 必须提交到 Git，且禁止手动生成
很多团队把 composer.lock 加进 .gitignore，这是最常踩的坑。它不是“临时文件”，而是依赖精确快照。
- 每次
composer update后必须git add composer.lock并提交 - CI/CD 流水线部署时，必须用
composer install --no-dev --optimize-autoloader（不是update） - 禁止在生产机上运行
composer update：没锁文件约束，等于裸奔
私有包和离线恢复：用 composer archive 打包 vendor
当项目含私有 Git 包、或需断网部署时，仅靠 lock 文件不够。这时要固化 vendor/ 内容本身：
- 本地执行：
composer archive --format=zip --dir=dist/ myapp-20261026.zip，生成含全部依赖的 zip - 该命令会自动排除
.git、tests/等非运行时目录，体积比直接zip vendor/小 30%~50% - 解压后直接
cp -r dist/myapp-20261026.zip . && unzip myapp-20261026.zip -d vendor/，跳过网络拉取 - 注意：该 zip 不含
autoload.php自动加载逻辑，仍需确保vendor/autoload.php路径正确
和 MySQL 备份脚本联动的关键时机
Composer 状态和数据库备份必须时间对齐，否则代码已升级、数据还是旧结构，一启动就报错：
- 在你的 MySQL 备份脚本（如
mysql_bakup.sh）末尾追加一行：cd /path/to/project && composer archive --format=zip --dir=/home/mysql/backup/ vendor-$(date +%Y%m%d_%H).zip - 不要在备份前删
vendor/——archive命令读的是当前已安装状态，删了就打空包 - 备份日志里记两行：
MySQL backup: mysql_student-20261026_23.sql和Vendor archive: vendor-20261026_23.zip，恢复时严格按同时间戳配对
真正容易被忽略的是：vendor 打包和数据库备份之间没有原子性。哪怕只差 3 秒，用户刚提交一笔订单，数据库写入了但 vendor 还没打包完，这个时间窗口就是 RPO（恢复点目标）的实际值。所以高一致性场景，得加锁或停写一小段时间——不是技术做不到，而是多数人根本没意识到这 3 秒存在。
