composer.lock不能回滚，只能通过Git恢复历史版本并清理vendor后执行composer install才能生效；手动修改或误合并会导致JSON解析失败，必须用git checkout --ours/--theirs恢复再删vendor重装。
composer.lock 不能“回滚”——它只能被替换或恢复，且必须配合 vendor 目录清理才能生效。
为什么 composer install 不按 lock 文件装旧版本
常见现象是：你明明有旧版 composer.lock，执行 composer install 后 vendor/ 里还是新包，甚至报错找不到类。根本原因不是命令失效，而是你当前用的 composer.lock 并非目标版本。
- 先运行
git status composer.lock：如果显示modified或not staged，说明它已被改过，不是你要的那个快照 - 若旧版 lock 已提交，直接恢复：
git checkout HEAD~1 -- composer.lock（或指定具体 commit hash） - 删干净
vendor/：rm -rf vendor（Windows 用户请手动删除整个文件夹） - 再跑
composer install——此时它才真正只读 lock、完全忽略composer.json的版本约束 - 别用
composer update --lock：它只是重写 lock，不清理 vendor，也不会回退任何已安装代码
Git 合并冲突时误编辑 composer.lock 怎么办
composer.lock 不是普通 JSON 文件，它是整个依赖树的序列化快照，字段顺序、空格、嵌套层级都参与哈希计算。手动删字段、调格式、合并时手改内容，大概率导致后续 composer install 报 JSON decode error 或类加载失败。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 正确做法是先用 Git 恢复干净版本：
git checkout --ours composer.lock（保留当前分支）或git checkout --theirs composer.lock（采用对方分支） - 然后删掉
vendor/，再执行composer install - 如果恢复后的
composer.lock和当前composer.json不匹配（比如 json 里加了新包但 lock 里没记录），composer install会立刻报错，逼你确认到底要哪套依赖 - 若只是想让 lock 和当前 vendor 对齐（比如你本地改过包但没更新 lock），用
composer update --lock即可，它只重写 lock，不装不卸
只想降级某一个依赖包，怎么避免连带升级其他包
最常被误操作的场景：手动改 composer.json 版本号后跑 composer update，结果触发全新依赖解析，把 guzzlehttp/guzzle 升了，monolog/monolog 也跟着变了。
- 查可用历史版本：
composer show -a monolog/monolog，确认v2.9.2存在且未被标记为abandoned - 执行：
composer require monolog/monolog:^2.9 --with-all-dependencies——加--with-all-dependencies是关键，防止子依赖冲突时静默跳过 - 它会更新
composer.lock中该包的version、dist/sha256和所有间接依赖项，比手动编辑安全得多 - 如果报
Your requirements could not be resolved，运行composer why-not monolog/monolog:2.9.2查具体冲突来源 - 注意：不要用
composer update vendor/package:old-version来降级——这个命令在 Composer v2.5+ 中已被弃用，行为不稳定
真正麻烦的点不在命令本身，而在于 lock 文件和 vendor 目录的状态是否同步、是否被 Git 正确跟踪。很多人卡住，是因为以为 composer install 会“智能识别”该装什么，其实它只认 lock 里的字面值，多一个空格、少一个字段，都可能让整个依赖树失效。
