dev-master易触发冲突，因其不遵循SemVer规则，直接映射Git最新提交哈希，导致版本不可比、约束失效、依赖解析失败，且绕过conflict校验与composer why-not检测。
开发分支（dev-master、dev-develop）引入的依赖冲突，本质是版本约束失效 + 解析器失去语义化锚点，不是“版本太新”，而是“没有版本”。
为什么 dev-master 容易触发冲突？
Composer 对 dev- 分支的处理方式和稳定版完全不同：它不按语义化版本（SemVer）解析，而是直接映射到对应 Git 分支的最新提交哈希，并跳过所有 ^、~ 约束的逻辑判断。这意味着：
- 多个包都 require
"monolog/monolog": "dev-master"，Composer 无法判断它们是否“兼容”——因为没版本号可比，只能硬拉同一份 commit，但若各自锁在不同 commit，就会卡在Resolving dependencies阶段不动 - 一个包 require
"monolog/monolog": "^2.0"，另一个 require"monolog/monolog": "dev-master"，Composer 会认为二者无交集（前者要满足 SemVer 规则，后者拒绝被规则约束），直接报Your requirements could not be resolved -
dev-分支不参与conflict和replace的常规校验，容易绕过你设的保护逻辑
composer why-not 对 dev- 分支基本无效
运行 composer why-not monolog/monolog:dev-master 很可能返回空或误导性结果，因为 why-not 依赖已安装包的 composer.json 中明确声明的版本约束，而 dev- 分支在 composer.lock 里只存 commit hash，不存约束表达式。此时更可靠的做法是：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先查真实安装状态：
composer show monolog/monolog，确认输出中source字段是否为git类型、reference是否为具体 hash - 用
composer depends monolog/monolog看哪些包显式 require 它，再逐个进对应包的composer.json查是否写了dev-分支 - 临时切回稳定版验证：
composer require monolog/monolog:^2.9 --update-with-dependencies，看是否立刻成功——如果成功，基本锁定是dev-引入的解析混乱
如何安全使用开发分支而不引爆依赖树？
真需要跟踪某个包的开发进度，别直接写 dev-master。更可控的方式是：
- 用
dev-develop#commit-hash替代dev-develop，例如"monolog/monolog": "dev-develop#abc1234"，把不确定性收束到单次提交，避免每次update都拉新内容 - 在根项目
composer.json中显式加"minimum-stability": "dev"，并配"prefer-stable": true，让 Composer 在有稳定版时优先选它，仅在必须时退到 dev - 禁止在
require-dev以外的地方使用dev-分支——尤其是生产环境依赖链中混入dev-，会导致composer install在 CI 上行为不一致 - 若某私有包必须依赖
dev-，把它自己的composer.json中对下游的约束放宽，比如把"phpunit/phpunit": "dev-main"改成"phpunit/phpunit": "^9.5 || ^10.0"，再通过conflict排除已知崩溃版本
最常被忽略的一点：Composer 不会警告你 dev- 分支正在悄悄覆盖稳定依赖的 API 行为。哪怕 composer update 成功了，运行时也可能因某次未测试的 commit 导致 Monolog\Logger::error() 多了一个参数而崩掉——这种问题不会出现在 composer.lock 差异里，得靠单元测试兜底。
