composer install报错是校验失败的必然结果，因手动修改lock会破坏content-hash导致校验失败；正确恢复方式是用git checkout还原lock、删vendor后重装，而非用update重建。
composer.lock被手动修改后install报错是校验失败的必然结果
Composer install不是“读取lock然后装包”，而是先校验lock文件完整性再执行安装。任意手动改动（删行、调顺序、改缩进、补空格）都会破坏content-hash字段，导致后续install直接中断并报Your lock file does not contain a compatible set of packages或checksum mismatch。
哪些操作会触发content-hash失效
content-hash是Composer对composer.json内容生成的SHA256摘要，lock文件里这个值必须和当前json完全匹配。以下操作会让hash不一致：
- 在
composer.json中增删空格、换行、注释（哪怕只是多一个空格） - 修改
require或require-dev里的版本约束（如"guzzlehttp/guzzle": "^7.0"改成"^7.1"） - 调整
config.platform、minimum-stability等影响依赖解析的字段 - Git合并时用文本编辑器“手动解决冲突”，而不是用
git checkout --ours还原lock
误改lock后怎么安全恢复
不要试图“修好”它——lock文件不是配置文件，它是不可编辑的快照。正确做法是放弃修改，重建一致性：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
git checkout --ours composer.lock或git checkout --theirs composer.lock（推荐选目标分支，如main） - 删掉
vendor/目录：rm -rf vendor/ - 执行
composer install——它会基于当前composer.json和刚恢复的lock校验并重装 - 如果报
Your lock file does not contain a compatible set of packages，说明composer.json已被他人提交变更，先git pull再重试
为什么不能用composer update来“修复”坏掉的lock
composer update会忽略当前lock，重新解析composer.json并生成全新lock——这等于放弃原有依赖版本锁定。你本地可能装上guzzlehttp/guzzle 7.9.0，而CI跑出7.8.1，行为漂移就此开始。真正需要的是还原，不是升级。
最常被忽略的一点：lock文件一旦被破坏，它就不再是“可修复”的配置项，而是整个依赖图的失效凭证。重建比调试更可靠。
