唯一可靠回滚方式是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 会触发全新依赖解析，可能连带升级其他包，不是还原，而是另一次不确定的安装

三步完整回滚必须严格执行

这三步缺一不可，顺序不能颠倒，中间不能跳过或简化：

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• 从 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 中自动刷新，必须人工确认。