composer.lock冲突本质是依赖树真实不一致，非git误报；必须用composer update --lock重建，禁用手动编辑，否则破坏content-hash致install失败。
composer.lock冲突本质是内容分歧，不是Git误报
它不是普通JSON文件，而是带content-hash校验的二进制语义结构：每次composer update、composer require、甚至不同Composer版本或PHP小版本（如8.1.22 vs 8.1.25）都会重写整个文件，字段顺序、空行、哈希值全变。多人各自运行后提交，Git标出冲突是真实的——不是格式问题，是依赖树已不一致。
冲突发生时，立刻丢弃当前lock，用composer update --lock重建
手动编辑composer.lock必失败：合并标记会让JSON解析直接崩溃；删空行、调缩进、改字段顺序会破坏<code>content-hash，后续composer install报Invalid argument supplied for foreach()或静默装错包。
- 先确保
composer.json已无冲突（git checkout --theirs composer.json或手动整合） - 删掉当前冲突的
composer.lock（或mv composer.lock composer.lock.bak） - 运行
composer update --lock——它只读composer.json，不依赖旧lock，生成全新合法lock - 如果报
Your requirements could not be resolved，说明两个分支的composer.json存在真实不兼容（比如PHP版本约束冲突），必须先协调json再重试
预防比解决更重要：让lock冲突变“稀有”
高频冲突根源是节奏失控。团队需同步三件事：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 所有依赖变更必须先改
composer.json，立即执行composer update --lock，一起提交——禁止只提json不提lock - 在
composer.json里加"config": { "sort-packages": true }，强制包列表按字母序排列，大幅减少“假冲突”（内容相同但顺序不同被Git标为冲突） - CI流程中加校验：
composer install --dry-run失败即阻断，倒逼开发者先拉最新composer.lock再提交 - Git配置
composer.lock merge=ours（写入.gitattributes）可避免自动合并，但不能替代人工同步json
CI/CD里--no-lock是定时炸弹
有些团队为绕过lock冲突，在CI脚本里写composer install --no-lock，结果上线环境装的包和本地开发机完全不一致——安全补丁没上、间接依赖升级引发兼容问题、半夜报错根本无法复现。
正确做法是CI始终用composer install --no-interaction，并确保检出代码时composer.json和composer.lock严格匹配。一旦提示lock file is not up to date with composer.json，说明PR提交者漏跑了composer update --lock，应直接拒绝合并。
真正麻烦的从来不是怎么解一次冲突，而是某人悄悄在composer.json里加了"platform": {"php": "8.2"}却没同步说明，导致其他人本地composer install一直失败却查不出原因。
