直接结论：别碰 composer update，立刻用 composer install 回退到上一个可用的 composer.lock 状态——这是唯一能保证版本精确还原的操作。
直接结论：别碰 composer update，立刻用 composer install 回退到上一个可用的 composer.lock 状态——这是唯一能保证版本精确还原的操作。
为什么不能运行 composer update 回滚？
它不会回退，只会重新解析 composer.json，拉取最新兼容版本，大概率让问题更糟。错误日志里出现 Your requirements could not be resolved 或 Class not found 时，update 是加重故障的动作，不是解药。
真正起作用的是 composer install，它只读 composer.lock，按哈希、版本、嵌套依赖关系原样安装，不计算、不猜测、不升级。
- 如果
composer.lock还在，删掉vendor后执行composer install即可恢复 - 如果
composer.lock被误删或损坏，优先从 Git 恢复：git checkout HEAD^1 -- composer.lock - 若没开 Git，且
composer.json完整，可删vendor和composer.lock后再composer install——但此时生成的新 lock 文件和旧环境已不一致，仅作临时应急
composer.lock 损坏时怎么检测和修复？
损坏表现通常是 composer install 报 JSON 解析失败、file_get_contents(composer.lock): failed to open stream，或 composer validate 直接报错。
先跑 composer validate，它不联网、不装包，500ms 内就能告诉你 lock 文件是否合法。
- 如果输出
./composer.json is valid但./composer.lock is invalid：说明 lock 文件结构出错，直接删掉它 - 如果
composer.lock是空文件或乱码：删，然后composer install重建 - 如果只是某个包的
dist.sha256字段缺失或错位：别手修，运行composer update --lock，它只重写 lock 文件，不动 vendor
删 vendor 前必须做的三件事
很多人删完就 install，结果还是报错，问题常出在缓存、平台配置或 autoloader 上。
- 先清缓存：
composer clear-cache——否则损坏的 zip 包可能还在~/.composer/cache里，重装时继续解压失败 - 确认 PHP 版本匹配：
php -v和composer.json中"platform": {"php": "8.1.10"}一致，否则install会跳过兼容包或报require php ^8.1错误 - 检查是否用了
--no-dev：如果上次是composer install --no-dev，这次也得加，否则vendor/bin下会多出一堆测试工具，可能干扰 CI 或部署流程
没有版本控制时的紧急降级操作
Git 没提交过 composer.lock？或者服务器上压根没装 Git？这时只能手动干预，但风险明确：
你得知道哪个包导致崩溃。看错误日志里的类名或命名空间，比如 Class Spatie\Permission\Models\Role not found，基本就是 spatie/laravel-permission 版本不兼容。
- 编辑
composer.json，把问题包的版本号改回上一个稳定版，例如"spatie/laravel-permission": "^5.10"→"^4.6" - 删掉
vendor和composer.lock - 运行
composer install——它会按新composer.json生成 lock 并安装
这种操作绕过了 lock 文件的确定性保障，下次 composer update 可能又崩。真正的长期解法，是把 composer.lock 加进 Git，并在测试环境验证后再推生产。
