composer.lock损坏后不能删锁重跑install，必须用composer update --lock仅重写lock文件；若vendor也损坏则先删vendor再install；两者均不可信时才执行rm composer.lock && rm -rf vendor && composer update。
composer.lock 文件损坏后 install 直接失败
只要 composer install 报错提示 no lock file present、JSON decode error 或 Root composer.json requires xxx but it is not satisfied，基本可判定 composer.lock 损坏或与 composer.json 不匹配。它不是普通 JSON，字段顺序、空格、嵌套层级都参与哈希校验，手动编辑或 Git 合并冲突后强行保存会直接破坏一致性。
别删 lock 文件后跑 install，该用 update --lock
删掉 composer.lock 再执行 composer install 是无效操作——命令会直接报错或静默跳过，因为 install 的语义就是“按 lock 还原”，没 lock 就没依据。真正该做的是：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer update --lock：仅重写composer.lock文件，不改动已安装的vendor/，适合修复 Git 拉取时换行符错乱、手动误改、或 lock 被部分覆盖但 vendor 仍完好的情况 - 若
vendor/也已损坏（如文件缺失、autoload.php 生成失败），先rm -rf vendor/，再运行composer install（此时 lock 存在，能精确还原） - 只有当 lock 和 vendor 都不可信时，才走彻底重置：
rm composer.lock && rm -rf vendor && composer update
Git 合并冲突后怎么救回 lock 文件
遇到 这类标记出现在 <code>composer.lock 里，不能手动删冲突段。正确做法是：
- 用
git checkout --ours composer.lock或--theirs恢复任一干净版本（选你信任的分支） - 立刻
rm -rf vendor/，再composer install—— 如果当前composer.json和恢复的 lock 不兼容，会立即报错，逼你确认依赖状态 - 若想让 lock 对齐当前 vendor（比如你本地改过包但忘了
update），就跑composer update --lock，它只序列化当前 vendor 状态，不重装
为什么 update --lock 比直接删 lock + update 更安全
composer update 会重新解析所有约束，可能升级到带 BC break 的新版本；而 composer update --lock 只读取当前 vendor/ 中已安装的包信息，原样写入 lock，相当于“拍照存档”。它不检查 PHP 版本是否满足 composer.json 中的 platform 配置，也不更新任何包，因此不会引入意外变更。CI 流水线中修复丢失的 lock 文件，首选就是它。
