composer.lock冲突不能手动编辑，因其是依赖树完整快照，含精确版本、校验和等，混入git冲突标记会导致install失败；正确做法是先合并composer.json，再删composer.lock和vendor/，最后运行composer update重新生成。
多人协作中 Composer 依赖冲突不是技术问题，而是流程失控的信号——必须靠锁文件 + 明确分工 + 禁止随意 update 来兜底，否则每次合并都可能引入隐性环境差异。
为什么 composer.lock 冲突不能手动编辑
composer.lock 是依赖树的完整快照，包含每个包的精确版本、校验和、安装方式。Git 冲突标记（ / <code>>>>>>>）混在里面会导致 composer install 直接失败，报错类似 Invalid lock file format 或 hash mismatch。
常见错误现象：
- 保留一方的 lock 文件，但没同步另一方的
composer.json变更，导致某些包实际未安装 - 手动删掉冲突标记后保存，结果校验哈希失效，
composer install拒绝执行 - 只合并了 lock 文件，没跑
composer install验证，本地 vendor/ 与锁文件不一致
正确做法是：先人工合并 composer.json（注意 require 和 require-dev 区分），再删掉本地 composer.lock 和 vendor/，最后运行 composer update 重新生成锁文件。
团队里谁该执行 composer update
升级依赖等于修改运行时契约，不是“谁手快谁点”。必须由专人（如 Tech Lead 或 Infra 成员）发起，并附带明确说明：
- 升级原因是否为安全补丁（如 CVE-2026-XXXX）、PHP 版本适配，或功能必需
- 是否已用
composer why和composer why-not验证上下游兼容性 - 是否在 CI 中跑通全部测试（单元 + 集成 + 关键路径）
- 是否拆分 PR：先提交仅含
composer.lock更新的 PR，再提交业务代码
禁止在业务 PR 中夹带 composer.lock 变更——它本质是一次环境变更，需要独立评审。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
platform 配置为什么经常失效
"config": {"platform": {"php": "8.2.10"}} 只约束当前项目的 install 行为，**不覆盖子依赖自己声明的 PHP 要求**。
例如你锁了 PHP 8.2，但某个依赖包在其自己的 composer.json 中写了 "php": "^8.3"，Composer 仍会拒绝安装——它优先尊重子依赖的声明。
这意味着：
- 仅靠
platform无法统一团队 PHP 版本 - 必须在
Dockerfile、.php-version、CI 脚本中显式指定 PHP 版本 - CI 中需前置运行
php -v校验，避免因环境变量默认值不同导致composer install行为不一致
如何让 composer install 真正“可重现”
关键不在命令本身，而在配套动作是否闭环：
-
composer install前，必须确保composer.lock已提交且无 Git 冲突 - 部署到生产时，必须加
--no-dev --optimize-autoloader，否则require-dev里的包也会被装进去 - CI 脚本中要显式设置
COMPOSER_NO_DEV=1，不能依赖环境变量默认值 - 新成员克隆项目后，只允许运行
composer install，严禁composer update
最容易被忽略的一点：当 composer.lock 被修改时，它不是一次普通提交，而是一次实质性的环境变更——它的哈希变化，意味着 vendor/ 目录内容已不可逆地改变。这点必须写进团队《Composer 使用指南》，而不是靠口头约定。
