不能手动解决composer.lock Git冲突，因其是依赖图哈希快照而非普通JSON：残留合并标记致JSON解析失败；微小格式改动（顺序、缩进等）使content-hash失效，引发静默装错包、运行时类找不到等问题；正确做法是先整合composer.json，删掉冲突lock，再执行composer update --lock重建合法锁文件。
为什么不能手动解决 composer.lock 的 Git 冲突
因为 composer.lock 不是普通 JSON 配置文件，而是整个依赖图的哈希快照。Git 合并后残留的 <<<< HEAD 或 >>>> origin/main 会直接导致 composer install 报 JSON decode error: Syntax error；即使你手动删掉这些标记，只要改了 packages 数组顺序、缩进、空行或字段位置，content-hash 就会失效——后续安装可能静默跳过校验，但运行时类找不到、方法不存在、dist.sha256 不匹配等问题全都会出现。
冲突发生后必须执行 composer update --lock
这不是“升级依赖”，而是丢弃当前冲突文件，仅依据已合并无误的 composer.json 重新生成合法锁文件。操作前确保：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer.json已通过git merge或git rebase完成整合（比如双方都加了新包，或 PHP 版本约束已统一） - 删掉本地
composer.lock（或先mv composer.lock composer.lock.bak） - 运行
composer update --lock—— 正常输出应为Lock file operations: 0 installs, 0 updates, 0 removals - 若输出中出现大量
Updating xxx，说明composer.json还没真正拉齐，得先git pull origin main再重试
CI/CD 中最常踩的坑：--no-lock 和缓存错位
composer install --no-lock 是定时炸弹：它绕过 composer.lock 直接按 composer.json 解析依赖，结果线上装的包和本地开发机完全不一致——安全补丁漏掉、间接依赖意外升级、半夜报错无法复现。更隐蔽的问题是 CI 缓存机制：
- GitHub Actions / GitLab CI 默认可能复用旧的
composer.lock缓存，导致composer install实际读的是过期 lock，而非当前分支最新提交的那份 - 必须在 CI 第一步显式检查：
ls -la composer.lock，确认文件存在且时间戳与当前 commit 匹配 - 禁用 vendor 缓存，或显式配置
cache: false（部分平台需强制关闭） - 部署脚本里别只写
composer install --no-dev，要加--no-interaction --optimize-autoloader，否则 autoload 未优化可能拖慢启动
预防比解决更重要：让冲突变“稀有”
高频冲突不是因为改得多，而是改得不一致。关键动作要落在配置和流程上：
- 在
composer.json顶层加"config": {"sort-packages": true}，再跑一次composer update --lock提交——这能消灭 70% 以上的“假冲突”（内容相同但顺序不同被 Git 标为冲突） - 所有依赖变更必须先改
composer.json，立即执行composer update --lock，然后git add composer.json composer.lock一起提交 - CI 加校验步骤：
composer validate --strict && composer install --dry-run，失败即阻断合并 - 功能分支里完成依赖变更后，尽快合入
main，避免长期 diverge 导致composer.json差异过大
composer.lock 是契约，不是草稿。 
