不能手动编辑 composer.lock 解决 git 冲突，因为它是 composer 生成的依赖快照，含精确哈希、依赖树、字段顺序等语义信息，手动修改会破坏 json 结构或校验值，导致安装失败或运行时错误。
为什么不能手动编辑 composer.lock 解决 Git 冲突
因为 composer.lock 不是普通 JSON 配置文件，而是 Composer 生成的依赖快照：它精确记录每个包的完整依赖树、dist.sha256 哈希、安装路径、平台约束（如 platform-check），甚至字段顺序都有语义——packages 数组里包的排列顺序影响 content-hash 计算。Git 合并工具或你手动删空行、调缩进、保留双方冲突块，都会破坏 JSON 结构或哈希一致性。
后果很直接：composer install 报 JSON decode error、Package xyz has a mismatched hash，或者更隐蔽地——静默降级某个子依赖，上线后类找不到、方法不存在，但本地开发却“刚好能跑”。
- 冲突标记（
）本身就会让 JSON 解析失败 - 即使侥幸通过解析，
packages顺序错乱会导致后续composer update行为不可预测 -
content-hash和platform-check是结果，不是配置项，手动改等于伪造校验值
遇到冲突时最安全的三步操作
别犹豫，放弃当前冲突内容，用 Composer 自己重建权威版本。前提是：先确保 composer.json 已正确合并（无冲突、语义一致）。
- 运行
git checkout --theirs composer.lock（或--ours，取决于你想以哪边composer.json为准） - 立即执行
composer install --no-scripts：验证该 lock 是否真能装出可用 vendor，不跑脚本避免副作用 - 再跑一次
composer update --lock：它只重写 lock 文件结构，不改任何包版本，输出会显示 “Lock file operations: 0 installs, 0 updates, 0 removals” —— 这才是干净状态
如果 composer update --lock 输出里有大量 “Updating” 行，说明你本地 composer.json 还没拉齐，得先 git pull origin main 并重新 merge composer.json。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer update --lock 和 composer install 的关键区别
很多人混淆这两个命令在冲突场景下的用途：composer install 是“按 lock 装”，composer update --lock 是“按 json 重算 lock”。前者要求 lock 文件本身合法且匹配当前环境；后者不依赖 lock，只读 composer.json，生成新 lock。
- 当你已有干净的
composer.json，但 lock 文件冲突损坏 → 用composer update --lock - 当你想快速验证对方分支的 lock 是否可靠 → 先
git checkout --theirs composer.lock，再composer install --no-scripts - CI/CD 中绝对禁止
composer install --no-lock：它绕过 lock 校验，导致线上装的包和开发机不一致，半夜出问题没法复现
注意：composer update --lock 不接受包名参数（如 composer update --lock monolog/monolog 会报错），它只做结构同步。
长期减少冲突的三个实操习惯
冲突高频发生，本质是协作节奏失控。真正省事的办法不是“怎么解”，而是“怎么不产生”。
- 在
composer.json里加"config": { "sort-packages": true }：强制 Composer 按字母序写入packages，大幅减少因插入顺序不同引发的“假冲突” - 所有依赖变更必须成对提交：
composer.json+composer.lock，禁止只提 json 不提 lock，也禁止手改 json 后不跑composer install - 每天早间由一人执行
composer update --dry-run检查安全更新，确认后统一在main提交新 lock，其他人基于该 commit 开发
最常被忽略的一点：团队里 PHP 版本不一致（比如有人用 8.1、有人用 8.2）会让 platform-check 和 content-hash 天然不同——这不是 bug，是设计使然。要么统一本地环境，要么接受这个差异只存在于 lock 文件末尾，不参与逻辑比对。
