删 composer.lock 和 vendor 后运行 composer install 是错误做法，因它不修复状态脱节，反而掩盖问题；composer.json 是愿望清单，composer.lock 是已验证的依赖快照，二者不一致源于未执行 composer update 同步变更。
直接删掉 composer.lock 和 vendor/，再跑 composer install 是错的——它不会修复不一致，反而可能掩盖问题。
为什么 composer.json 和 composer.lock 会不一致？
这不是文件损坏，而是状态脱节：你改了 composer.json（比如加了个包、升了 PHP 版本），但没运行 composer update 生成新锁文件；或者别人提交了更新后的 composer.json，却漏掉了 composer.lock。此时 composer install 会拒绝执行，并报类似 Root composer.json requires xxx, but it is not satisfied 的错误。
-
composer.lock是当前已验证可行的依赖快照，含精确版本、哈希、嵌套关系 -
composer.json是你的“愿望清单”，但没被求解器验证过是否真能落地 - 不一致 ≠ 冲突，但它是冲突的前置条件：install 失败是保护机制，不是 bug
如何安全同步二者状态？
目标不是让 lock 文件“看起来像” json，而是让 lock 文件真正反映 json 所述约束下可解出的最新一致依赖图。
- 先确认
composer.json本身合法：composer validate，修复语法或字段错误 - 检查平台兼容性：
composer install --dry-run，看是否因 PHP/扩展版本不匹配而卡住 - 若
composer.lock存在但过期，运行composer update --lock（Composer 2.5+ 支持）——它不改依赖版本，只用当前 json + 当前环境重算 lock 结构，修正平台字段和哈希 - 若要升级实际依赖，必须用
composer update，而非install；install永远只认 lock，不读 json 的新意图
常见误操作与后果
手动编辑 composer.lock 或用 --no-update 强行写入新 require，等于把依赖图交给运气管。
-
composer require xxx --no-update后直接提交 lock 文件：Composer 不校验一致性，下次install可能失败，CI 流水线会崩 - Git 合并时用
git checkout --ours composer.lock硬覆盖：丢掉对方新增的依赖约束，导致本地能跑、线上挂掉 - 删 lock + vendor 后跑
composer install：它退化为update行为，但无--dry-run预检，容易引入未测试版本
最易被忽略的细节
composer.lock 里的 platform 字段（如 "php": "8.2.10"）不是建议值，而是求解时的硬约束。它来自你上次运行 update 时的本地环境，不是 composer.json 里写的 "php": "^8.2"。如果你升级了 PHP，但没重新 update，lock 文件仍锁着旧平台快照，install 就会因平台不匹配而中止——这不是 bug，是设计使然。
