必须用 Git 提交 composer.lock 而非 composer update 同步，因为 update 会因 PHP 版本、扩展、平台配置等差异导致不同机器生成不一致的 lock 文件；只有 Git 才能确保所有环境消费同一份精确依赖快照。
靠 Git 提交 composer.lock，不是靠命令同步，也不是靠人手工复制。
为什么不能用 composer update 同步 lock 文件
执行 composer update 会重新解析整个依赖树，结果取决于当前机器的 PHP 版本、扩展状态、平台配置（config.platform）甚至镜像源响应顺序。同一份 composer.json，在 A 机器上跑出的 composer.lock 和 B 机器上很可能不一致——哪怕只差一个 patch 版本或一个扩展模拟开关。
- CI 流水线里写
composer update，等于放弃版本控制权 - 本地改完
composer.json后直接composer update，再把新composer.lock提交，是唯一合法路径；但“同步”动作本身仍是 Git 推送/拉取，不是 Composer 做的 -
composer install不生成 lock，只消费 lock；它根本不参与“同步”过程
Git 提交 composer.lock 的硬性条件
它不是缓存文件，是契约快照。不提交，就等于没锁版本。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 检查
.gitignore是否误写了composer.lock或*lock* - 新项目第一次
composer install后，立刻git add composer.lock - 多人协作时，只要有人改了
composer.json并运行了composer update，就必须把新composer.lock提交——否则别人git pull后composer install会报错：Your lock file does not contain a compatible set of packages - 合并分支遇到
composer.lock冲突？不要手动编辑，应以某一方的 commit 为准，git checkout --ours composer.lock或--theirs，再composer install验证是否能装通
跨环境 lock 兼容性失效的常见原因
不是 lock 文件本身坏了，而是生成它的上下文和你当前环境不匹配。
-
composer.lock顶部的platform字段记录了生成时的 PHP 和扩展模拟值。若团队未统一声明，比如有人用"php": "8.2.5"，有人用"php": "8.1.0"，依赖解析结果可能分叉 - 解决办法：在
composer.json中显式固定"config": {"platform": {"php": "8.1.0"}}，所有成员和 CI 都按这个“虚拟环境”生成 lock - Windows 和 Linux 对
ext-sockets、ext-posix等默认状态不同，若项目依赖它们，必须在platform中统一模拟，否则 lock 在 CI 成功，本地失败 -
content-hash字段校验的是composer.json + platform + lock 结构，不是代码内容。它一致只说明“声明一致”，不代表 vendor 实际字节相同
真正难的从来不是怎么生成 lock，而是让所有人理解：lock 文件不是产物，是协议；Git 才是同步通道；而 platform 配置，是这份协议生效的前提条件。
