必须在CI/CD deploy阶段、git checkout后、composer install前自动备份composer.json和composer.lock；命名格式为环境-YYYYMMDD-HHMM-文件名（如prod-20261104-1430-composer.lock），存至持久化路径并立即校验完整性。
composer.json 和 composer.lock 必须在每次发布前自动备份，靠人工复制粘贴等于没备。
备份动作必须集成进发布脚本，不能依赖 crontab 定时
crontab 定时备份项目根目录下的 composer.json 和 composer.lock 是无效做法——它无法感知「哪次是生产发布」，更无法绑定具体 commit 或环境上下文。
真正可靠的备份时机只有一个：CI/CD 流程中 deploy 阶段、git checkout 之后、composer install 之前。
- 备份命令必须带环境标识和精确时间戳，例如：
cp composer.{json,lock} releases/prod-$(date +%Y%m%d-%H%M)-composer.{json,lock} - 命名格式强制为
环境-YYYYMMDD-HHMM-文件名，如prod-20261104-1430-composer.lock - 禁止使用
latest.json、backup.lock这类无追溯性的名字 - 若项目多环境（prod/staging），应按环境分目录，如
releases/prod/和releases/staging/
备份路径需避开 git ignore 和临时目录
很多团队把备份扔进 backup/ 或 tmp/ 目录，结果被 .gitignore 过滤掉，或随容器重建丢失。
正确做法是：
- 使用独立的持久化路径，如
/data/backups/myapp/（挂载卷）或对象存储（S3/MinIO） - 若走本地文件系统，确保该路径不在
git status范围内，也不在vendor/或runtime/这类易清空目录下 - 不要将备份写入项目工作区内部（如
./backups/），CI 构建缓存清理时可能一并删掉
CI 中验证备份完整性比备份本身更重要
只拷贝文件不校验，等于埋雷。应在备份后立即加两步验证：
- 运行
composer validate --no-check-all检查composer.json格式合法性 - 运行
composer install --dry-run确认当前composer.lock能完整解析依赖，不报错、不卡在 “Resolving dependencies” - 若任一失败，整个发布流程应中断，而不是继续往下走
备份不是“存下来就完事”，而是“能还原、能验证、能定位”。漏掉 composer.lock 里的 dist.shasum 或私有 repositories 配置，回滚时连包都拉不下来。
