composer install必须读composer.lock，因其设计目标是“原样还原”：严格按锁文件中的精确版本号、dist url、sha256校验值和完整依赖树安装，完全忽略composer.json中的^或~版本约束。

因为没有 composer.lock，composer install 就不是安装，而是隐式执行一次不可控的 composer update。

为什么 composer install 必须读 composer.lock

composer install 的设计目标从来不是“满足版本约束”，而是“原样还原”——它只认 composer.lock 里写的精确版本号、dist URL、sha256 校验值和完整依赖树，完全忽略 composer.json 中的 ^7.0 或 ~2.5。

• 常见错误现象：Class 'Symfony\Component\HttpClient\HttpClient' not found —— 本地能跑、CI 报错，大概率是 composer.lock 没提交或被 .gitignore 误删
• 同事装出 guzzlehttp/guzzle 7.8.1，你装出 7.9.0，但两人都没动 composer.json？说明 lock 缺失，install 实际执行了隐式 update
• 性能影响：跳过整套依赖解析过程，安装速度显著快于 update；无 lock 时首次 install 不仅慢，结果还不可复现

删掉 composer.lock 会发生什么

等价于主动放弃环境一致性契约，不是“重新生成”，而是“重抽一次签”：

Workflow Decomposer

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

下载

• 子依赖可能悄悄降级（比如 monolog/monolog 从 2.9.1 退到 2.8.0，触发已知日志丢失 bug）
• 也可能升级到带 BC break 的小版本（如 phpunit/phpunit 从 9.6.15 升到 9.6.16，assertStringContainsString() 行为变更）
• composer install 不会报错，但会静默生成新 lock，且 content-hash 字段已变，后续 composer validate 会警告 The lock file is not up to date

Git 冲突时为什么不能手动编辑 composer.lock

它不是普通 JSON 配置文件，而是整个依赖图的完整序列化快照，字段顺序、空格、哈希值都参与校验：

• 手动删冲突标记、保留“这边的包 + 那边的哈希”、用格式化工具“美化”——99% 导致后续 composer install 失败或运行时 Class not found
• 正确做法是先确保 composer.json 已合并完成（可用 git checkout --theirs composer.json 快速采纳远端），再执行：
  • git checkout --ours composer.lock 或 git checkout --theirs composer.lock（任选其一恢复）
  • rm -rf vendor/
  • composer install —— 它会基于当前 composer.json 和刚恢复的 lock 校验并生成新 lock
• 如果提示 Your lock file does not contain a compatible set of packages，说明 composer.json 已被他人修改，先 git pull，再 composer install

真正容易被忽略的点在于：composer.lock 的效力依赖于基础环境的一致性——比如 platform 配置不匹配、PHP 版本差异、甚至不同 Composer 主版本生成的 lock 结构顺序不同，都可能导致看似相同的文件内容，在不同机器上触发校验失败或依赖漂移。