唯一可靠回滚方式是Git恢复旧composer.lock+彻底删除vendor+运行composer install；因Composer不记录历史，只认lock文件为唯一真相，其他操作均会残留autoload、opcache或bin脚本导致行为异常。
回滚失败的 Composer 依赖升级，唯一可靠方式是 Git 恢复旧 composer.lock + 彻底删除 vendor + 运行 composer install；任何“部分还原”或“跳过重装”的操作都会留下 autoload、opcache 或二进制残留，导致行为不可控。
为什么不能用 composer update --rollback 或手动改 composer.lock
Composer 不记录操作历史，也不维护本地变更栈。它只认 composer.lock 文件为当前依赖的“唯一真相”。所谓“失败的升级”，本质是你运行了 composer update，它生成了一个新的 composer.lock，并可能部分写入了 vendor/。此时：
-
composer update --lock只会重新计算并覆盖 lock 文件，完全不碰vendor/，旧代码仍在磁盘上，类仍可能被加载 - 手动编辑
composer.lock回填旧版本和哈希是高危行为：一旦dist.url或shasum与 Packagist 当前实际内容不一致，composer install会静默下载最新版，而非你期望的旧版 -
composer require vendor/package:old-version会触发全新依赖解析，可能连带升级其他包，不是还原，而是另一次不确定的安装
三步完整回滚必须严格执行
这三步缺一不可，顺序不能颠倒，中间不能跳过或简化：
- 从 Git 恢复上一个可用的
composer.lock：比如刚update出问题，立刻执行git checkout HEAD~1 -- composer.lock；如果已提交新 lock，就用git checkout abc1234 -- composer.lock（替换为对应 commit hash） - 彻底删除
vendor目录：用rm -rf vendor（Linux/macOS）或rmdir /s vendor（Windows），不能只删子目录或留vendor/autoload.php - 运行
composer install（不是update）：它会严格按刚恢复的composer.lock下载、解压、安装每个包的 exact 版本，并重建 autoload 映射
回滚后仍报错？检查这些残留点
即使三步做完，以下环境残留常导致“看似回滚成功，实则行为异常”：
-
opcache未清：PHP 可能仍在执行旧版本类的缓存字节码，需执行opcache_reset()或重启 Web 服务（如sudo systemctl restart php8.2-fpm） -
vendor/bin/下脚本残留：比如旧版phpunit仍存在且在PATH中优先被调用，检查并手动删掉vendor/bin/phpunit等二进制文件 - 第三方钩子未重放：某些包的
post-install-cmd（如生成配置、编译资源）在旧 lock 对应的安装中会执行，但你只重装了代码，没触发这些命令
最易被忽略的是 opcache 和 vendor/bin 脚本——它们不会随 vendor 目录一起被删干净，也不会在 composer install 中自动刷新，必须人工确认。
