唯一安全路径是删除冲突的 composer.lock 并执行 composer update --lock 重建，因其是依赖图哈希快照，手动编辑或 git checkout 会破坏语义完整性，必须通过合法契约重新生成。
composer.lock冲突不是Git问题，是依赖树真实不一致
直接删掉冲突的 composer.lock，执行 composer update --lock 重建——这是唯一安全路径。它不是“修文件”，而是丢弃快照，用已合并干净的 composer.json 重新生成合法依赖契约。
常见错误现象包括：JSON decode error: Syntax error（冲突标记残留）、Package xyz has a mismatched hash（字段顺序或缩进改动导致 content-hash 失效）、The lock file does not contain the required package "xxx"（git checkout --ours 强行保留某方 lock，但对方 composer.json 新增包未写入）。
- 冲突发生前必须确认
composer.json已无 Git 冲突，且语义正确（比如确认"monolog/monolog": "^3.0"是双方共识） - 删掉本地
composer.lock和vendor/目录，避免旧缓存干扰 - 运行
composer update --lock，观察输出：理想状态是Lock file operations: 0 installs, 0 updates, 0 removals；若出现大量Updating xxx，说明composer.json还没真正拉齐，需先git pull origin main
为什么不能手动编辑或用 git checkout --ours 解决冲突
composer.lock 不是普通 JSON 配置文件，它是整个依赖图的哈希快照。任何文本级操作都会破坏其语义完整性。
Git 合并标记（、=======、>>>> origin/main）本身就会让 composer install 直接报错；即使手动删掉，以下改动仍会导致静默故障：
-
packages数组顺序不同 →content-hash计算结果不一致 → 后续composer install报校验失败 - 缩进、空行、字段位置被调整 → Git 触发“假冲突”，掩盖真实依赖差异
-
platform字段（如"php": "8.2.0"）因本地 PHP 版本不同而自动变更 → 两边 lock 看似只差一行，实则环境语义已分裂 - 用
git checkout --ours选内容 → 可能丢失require-dev包、跳过平台约束校验、或装出与composer.json不匹配的版本
团队协作中让 composer.lock 变更只改几行的关键配置
高频冲突不是因为改得多，而是改得不一致。统一生成规则后，90% 的“爆红”其实是假冲突。
- 在
composer.json中启用"config": { "sort-packages": true }，再运行一次composer update --lock提交。这能强制packages数组按字母序排列，消除因顺序不同引发的 Git 差异 - 所有新成员加入项目前，必须执行
composer config -g sort-packages true全局启用，否则第一次composer require就会打乱顺序 - 禁用裸
composer update，改用composer update vendor/package-name --with-dependencies精确控制影响范围 - CI 脚本第一步加
composer install --dry-run校验：失败即阻断 PR 合并，说明有人改了composer.json却没提交新composer.lock
CI/CD 中最常踩的坑：--no-lock 和缓存错位
composer install --no-lock 不是省事，是放弃环境一致性。线上装的包和本地开发机可能差好几个小版本，安全补丁漏掉、BC break 暴露在线上，而你本地还复现不了。
- 部署脚本里别只写
composer install --no-dev，要加--no-interaction --optimize-autoloader，否则 autoload 未优化可能拖慢启动 - GitHub Actions / GitLab CI 默认可能复用旧的
composer.lock缓存，导致composer install实际读的是过期 lock。必须在 CI 第一步显式检查：ls -la composer.lock，确认文件存在且时间戳与当前 commit 匹配 - 禁用
vendor缓存，或显式配置cache: false（部分平台需强制关闭） - 运行
composer show --platform对比 CI 和本地输出的php、ext-intl、lib-curl是否一致；不一致时先统一 Dockerfile 或.php-version，再重建 lock
真正的麻烦不在冲突发生时，而在没人意识到 composer.lock 是构建指纹——它改一次，就得验证一次，就得同步一次。只要 composer.json 动了，composer.lock 就必须跟着动，且只能由 composer update --lock 生成。
