应删除冲突的composer.lock和vendor目录，再运行composer update --lock从当前composer.json重算依赖树；手动缝合lock文件会导致content-hash不匹配、包版本矛盾等逻辑错误，必须通过重生成确保一致性。
团队协作中 composer install 报错，90% 不是依赖本身有问题，而是 composer.lock 文件在 Git 合并时被手动“缝合”出了逻辑矛盾——比如保留了 A 分支的 monolog/monolog v2.9.3，又保留了 B 分支的 guzzlehttp/guzzle v7.8.1，但这两个版本实际无法共存。
别碰 conflicted lock 文件里的 >>>>>> 标记
Git 冲突标记只是文本提示，不是可执行状态。直接删掉标记、拼凑两段哈希、或按编辑器提示“接受两边”，都会导致 composer.lock 里出现：
- 同一个包在 packages 和 packages-dev 中版本不一致
- content-hash 与实际依赖树不匹配
- 某些包的 dist 信息残留旧 URL 或校验失败
- 一旦保存这种“半成品 lock 文件”，
composer install就会报Invalid argument: package xxx not found或静默跳过安装 - 不要用 IDE 的“自动合并 lock 文件”插件——它们只比对 JSON 结构，不校验依赖图有效性
- 真正有效的合并动作只有一次：
composer update --lock，它会丢弃所有冲突标记，从当前composer.json重算整棵树
先合 composer.json，再删 vendor 和 composer.lock
冲突根源永远在 composer.json 的 require 差异，而不是 lock 文件本身。多人同时加包，必然导致 require 列表不一致。
- 用
git merge或 PR 界面手动合并composer.json，确保所有新增包都出现在最终版本里（包括版本号） - 确认合并后没有语法错误：
json_decode(file_get_contents('composer.json'), null, 512, JSON_THROW_ON_ERROR) - 删掉本地
vendor/目录和composer.lock（不是“重命名”，是彻底删除） - 运行
composer update --lock—— 注意不是install，因为此时没有 lock 文件可遵循
composer update --lock 失败？检查 PHP 版本和 platform 配置
如果 composer update --lock 报 requires php ^8.1 but your PHP version (7.4.33)，说明你本地 PHP 环境和 composer.json 中的 "php": "^8.1" 不匹配，不是 lock 文件问题。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先执行
php -v和which php，确认终端调用的是目标 PHP 二进制 - 检查
composer.json的require段是否真写了"php": "^8.1"—— 如果没写，Composer 就不会校验，报错一定来自其他包的子依赖 - 别动
config.platform.php：它只该用于 CI 打包，本地开发时设了反而掩盖真实环境问题 - 临时调试可用
--ignore-platform-req=php，但必须立刻跟进git diff composer.lock，确认没混入 PHP 8.1 语法的包
CI 或上线前必须验证 lock 文件是否可复现
新生成的 composer.lock 能否被别人成功 install，取决于两点：是否所有包都能从 Packagist 下载、是否所有约束在目标 PHP 版本下可满足。
- 在干净目录下测试：
rm -rf vendor composer.lock && composer install - 检查输出末尾是否有
Generating autoload files，没有就说明 autoload 配置有误（常见于修改了autoload后忘了composer dump-autoload） - 提交前运行
composer validate，它会检查 lock 文件哈希是否与当前composer.json匹配 - 如果项目用了私有仓库，确保
repositories配置已提交且认证方式稳定（如使用 token 而非个人密码）
最常被忽略的一点：lock 文件的变更不是“技术细节”，而是契约。谁改了它，谁就得负责验证所有环境能装、能跑、不出 ParseError。手动合并标记看似快，实则把验证成本转嫁给下一个 composer install 的人。
