不能手动编辑composer.lock，因其是带语义的二进制安全快照，字段顺序、packages数组排列、dist.sha256和platform-check等均影响content-hash校验与依赖解析，git冲突标记会直接导致json解析失败或运行时异常。
直接删掉 composer.lock 再 composer install 是最危险的“快解法”——它大概率导致本地、CI、线上三端依赖不一致，运行时类找不到、方法不存在、哈希校验失败都是轻量级后果。
Git 合并时 composer.lock 报冲突，为什么不能手动编辑？
因为 composer.lock 不是普通 JSON 配置文件，而是带语义的二进制安全快照：字段顺序影响 content-hash 计算，packages 数组排列决定依赖解析路径，dist.sha256 和 platform-check 字段一旦错位或被 Git 合并标记（如 ）污染，就会让 <code>composer install 直接拒绝执行，或静默装错子依赖。
常见错误现象包括：
-
Invalid argument supplied for foreach()（JSON 解析阶段崩溃） -
Package xyz has a mismatched hash（哈希校验失败） - 本地能跑通，CI 构建失败，线上报
Class not found
composer update --lock 是唯一安全重建命令
它不安装/卸载任何包，只读取当前 composer.json，重新生成结构合法、哈希自洽的新 composer.lock。前提是：composer.json 本身已无冲突且语义正确。
实操步骤：
- 先确认
git status中只有composer.lock显示 unmerged，composer.json必须干净（可git checkout --theirs composer.json强制拉主干） - 删掉当前冲突的
composer.lock（或先mv composer.lock composer.lock.bak备份） - 运行
composer update --lock；理想输出是Lock file operations: 0 installs, 0 updates, 0 removals - 若输出含大量
Updating xxx，说明composer.json还没同步干净，需先git pull origin main并重试
团队协作中如何大幅降低冲突频率？
冲突本质不是 Git 问题，而是多人在不同环境（PHP 版本、扩展、执行时机）下生成了结构不一致的快照。预防比解决更重要。
关键配置与流程：
- 在
composer.json的config段加"sort-packages": true，强制packages数组按字母序排列，消除“假冲突” - 所有依赖变更必须原子提交：
composer require xxx或composer remove xxx后，立刻composer update --lock，再一起git add composer.json composer.lock - CI 脚本禁用
--no-lock，改用composer install --no-interaction，并加前置校验：composer validate --strict && composer install --dry-run - 在项目根目录加
.gitattributes文件，写入composer.lock -diff -merge，让 Git 直接拒绝合并，逼开发者走正确流程
真正容易被忽略的点是：很多人以为冲突发生在 composer.lock，实际根源常在 composer.json 没对齐，或某人本地用了不同 PHP 版本执行过 composer update —— 这些差异会固化进 platform-check 和 content-hash，但 Git 看不见，只能靠 composer update --lock 重新协商。
