composer.lock冲突不是git问题，而是依赖树真实不一致；git标红composer.lock时，不应急于编辑删除。
composer.lock冲突不是Git问题，是依赖树真实不一致
Git 标红 composer.lock 时，别急着打开编辑器删 ^2.10、B 分支锁了 ^3.0，也可能是 platform 配置（如 "platform": {"php": "8.1"}）不一致导致 content-hash 完全错开。这种冲突不是“格式错了”，而是 composer install 已无法复现任一分支的运行环境。
冲突发生后唯一安全操作：删 lock + composer update --lock
手动合并、git checkout --ours、在线 JSON 美化，全都会破坏哈希校验或字段顺序，后续 composer install 要么直接报 JSON decode error: Syntax error，要么静默装错包，类找不到才暴露问题。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先确保
composer.json已无冲突（可用git checkout --theirs composer.json或手动整合新增/删除的包） - 删掉当前
composer.lock（rm composer.lock，建议先mv composer.lock composer.lock.bak备份） - 运行
composer update --lock—— 它只读composer.json，不依赖旧 lock，生成全新合法快照 - 观察输出：
Lock file operations: 0 installs, 0 updates, 0 removals才表示composer.json已真正拉齐；如果出现大量Updating xxx，说明还有未同步的依赖变更，得先git pull origin main
为什么 sort-packages: true 是团队基础配置
没启用这个配置，两个人执行 composer require monolog/monolog，packages 数组顺序可能完全相反——内容一样，但 Git 全文件标红，Composer 不认这种“顺序自由”。这类“假冲突”占日常 lock 冲突的 70% 以上。
- 在
composer.json的config段加上"sort-packages": true - 所有依赖变更必须先改
composer.json，立刻执行composer update --lock，然后一起提交——禁止只提 json 不提 lock - CI 脚本必须加
composer validate --strict && composer install --dry-run，失败即阻断 PR 合并
CI 和上线环境绝不能用 --no-lock
composer install --no-lock 等于放弃锁文件存在的全部意义。CI 可能装出和你本地完全不同的子依赖版本，安全补丁漏掉、BC break 暴露在线上，而你本地还复现不了。
- CI 流水线中禁用
--no-lock，必须用composer install严格按 lock 安装 - 线上紧急修复时，只执行
composer update --lock（不碰vendor/），生成新 lock 后立刻提交 - 若
composer update --lock提示Your requirements could not be resolved，说明composer.json存在真实约束冲突，用composer why-not vendor/package:version定位阻断链，而不是放宽版本范围硬扛
composer.json 的变更节奏可控——谁改了什么、为什么改、改完立刻重建 lock 并提交，这三步缺一不可。否则每次 merge 都在赌运气。
