composer.lock冲突必须用composer update --lock重建，因其是带语义的依赖快照，字段顺序、packages排列、platform和dist.sha256均参与content-hash计算，手动删标记、保留一方或直接install会导致json解析失败、哈希不匹配或静默装错子依赖。
composer.lock冲突必须用composer update --lock重建，不是composer install
手动删冲突标记、保留某一方内容、或直接composer install跳过，都会导致JSON解析失败、哈希校验不通过、甚至静默装错子依赖。因为composer.lock不是配置文件，而是带语义的依赖快照：字段顺序、packages数组排列、platform字段（如"php": "8.2.0"）、每个包的dist.sha256全参与content-hash计算。
常见错误现象包括：
-
JSON decode error: Syntax error（Git冲突标记未清除） -
Package xyz has a mismatched hash（缩进/空行/顺序变动影响哈希） - 本地能跑，CI报
Class not found（间接依赖被意外降级）
正确做法是：composer update --lock——它不读旧composer.lock，只基于当前composer.json重算整个快照，确保结构合法、哈希自洽、子依赖一致。
冲突发生前必须先搞定composer.json，否则composer update --lock会失败
composer update --lock的前提是composer.json本身已无语义冲突。如果两个分支对同一包指定了互斥版本（比如A要"php": "^8.1"，B要"php": "^8.2"），或同时require了不兼容的包，composer update --lock会直接报Your requirements could not be resolved。
操作要点：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先用
git checkout --theirs composer.json或--ours选一个更接近目标分支的版本，再手工核对增删/版本号是否合理 - 运行
composer validate --strict确认语法和约束合法 - 若仍有冲突，用
composer prohibits vendor/package-name定位阻塞点 - 只有
composer.json干净了，composer update --lock输出才应是Lock file operations: 0 installs, 0 updates, 0 removals
镜像同步差异引发的“假冲突”怎么避免？
不同开发者用不同PHP版本、扩展、或国内镜像源执行composer update，会导致composer.lock中platform字段、dist.url、甚至packages顺序不一致——内容相同却被Git标为冲突。这不是bug，是快照必然携带的环境指纹。
降低假冲突的关键配置：
- 在
composer.json的config段加"sort-packages": true，强制packages按字母序排列 - 项目根目录加
.gitattributes，写入*composer.lock -diff -merge，让Git拒绝自动合并，逼人走composer update --lock流程 - CI脚本里加前置校验：
composer validate --strict && composer install --dry-run，失败即阻断 - 团队统一PHP版本（如用
.php-version或Dockerfile固定），避免platform字段漂移
多人协作中容易被忽略的细节
最常被跳过的动作，恰恰是最关键的安全阀：
- 依赖变更必须原子提交：
composer require xxx后立刻composer update --lock，再一起git add composer.json composer.lock - 不要在CI里用
--no-lock；该用composer install --no-interaction，并确保composer.lock已提交 -
composer update --lock不碰vendor/，但要求现有vendor/满足新约束——这其实是好事：提前暴露兼容性问题，而不是上线后崩 - 如果
composer update --lock输出里出现大量Updating xxx，说明composer.json还没真正拉齐，别硬着头皮提交
真正的难点不在命令本身，而在于所有人对composer.lock的认知：它不是可编辑的配置，而是契约；每次修改都必须经过Composer重算，而不是人眼比对。
