线上更新依赖前必须确认三件事：composer.lock已提交Git、启用维护模式、数据库迁移脚本测试通过；缺一则可能导致服务不可用、类加载失败或部署卡死。
线上更新依赖前必须确认的三件事
别急着跑 composer update，先看这三项有没有准备好：一是 composer.lock 是否已提交到 Git；二是当前环境是否启用维护模式（比如写个 down 文件或 Nginx 返回 503）；三是数据库迁移脚本是否已测试通过。缺一不可——漏掉任意一项，都可能让线上服务在更新中途不可用。
-
composer.lock没进 Git？那composer install在线上就失去锚点，所有依赖版本由composer.json动态解析，结果不可控 - 没开维护模式？用户请求可能命中一半新、一半旧的类，
Class not found或Call to undefined method会直接暴露给终端用户 - DB 迁移没验证？比如新包要求字段非空，而旧数据为空，
php artisan migrate或bin/console doctrine:migrations:migrate会卡死，锁住整个部署流程
自动化脚本里该用 install 还是 update
生产环境部署脚本里，永远用 composer install，而不是 composer update。后者会重算依赖树、改写 composer.lock，完全违背“线上环境确定性”原则。
-
composer install读取现有composer.lock，精确安装每个包的指定版本，速度快、行为可预测 -
composer update只该出现在开发环境，且需人工确认变更范围（git diff composer.lock必须过一遍） - CI/CD 中若要“更新依赖”，正确做法是：在 staging 环境运行
composer update→ 提交新的composer.lock→ 生产部署时仍走composer install
回滚失败的常见原因和对应操作
执行回滚后服务仍异常，大概率不是命令没跑对，而是忽略了底层状态一致性。最常踩的坑有三个：
-
vendor目录残留：删完再装，别信“部分重装”。执行rm -rf vendor（Linux/macOS）或彻底清空文件夹（Windows），再跑composer install -
opcache没清：PHP 的 opcode 缓存会继续加载旧类。加一句opcache_reset()到部署脚本末尾，或重启 PHP-FPM / Apache -
.env或配置文件不匹配：新旧依赖对配置项要求可能不同（比如某包 v3 要求新增QUEUE_CONNECTION），回滚后得同步还原配置
Git + lock 文件才是真正的回滚开关
别依赖任何“一键回滚”命令——composer self-update --rollback 只管 Composer 自身二进制，composer reinstall 仍受当前 composer.lock 约束。真正能控制依赖状态的，只有 Git 和 composer.lock 的组合。
- 回滚到上一个版本：
git checkout HEAD~1 -- composer.lock && composer install - 回滚到指定 commit：
git checkout abc1234 -- composer.lock && composer install - 如果
composer.lock已被覆盖且 Git 没提交？那就只能靠备份——提前把 lock 文件同步到对象存储或 NAS，别只靠本地 Git
回滚不是按下某个按钮就结束的事。它依赖你是否在每次更新前保留了可验证的锁文件快照，是否清理了运行时缓存，以及是否同步了配套配置。这些细节不处理，再快的自动化脚本也救不回一个挂掉的线上服务。
