^锚定主版本号，~锚定最左侧非零段；^1.2.3等价于>=1.2.3 <2.0.0，~1.2.3等价于>=1.2.3 <1.3.0；0.x下二者结果偶合但逻辑迥异，*在Composer中非法。
^ 和 ~ 的锚点根本不在同一坐标系里
很多人以为 ^ 是“宽松”，~ 是“严格”，其实它们连锚定位置都不同：^ 锚定主版本号（M），~ 锚定最左侧非零段（可能是 M，也可能是 M.N）。这不是松紧问题，是数学定义差异。
比如 ^2.8.0 等价于 >=2.8.0 ，允许升到 <code>2.99.99；而 ~2.8.0 等价于 >=2.8.0 ，连 <code>2.9.0 都不放行。写成 ~2.8 也不等于 ~2.8.*，它实际等价于 ~2.8.0，不是 >=2.8.0。
-
^1.2.3→ 允许1.9.9，但绝不会到2.0.0 -
~1.2.3→ 只允许1.2.99，1.3.0直接被拒 -
^0.5.1→ 实际只匹配>=0.5.1 ，<code>0.6.0视为 breaking -
~0.0.4→ 锚在第三位，可升到0.0.9，但不会到0.1.0
0.x 包的 ^ 约束比你写的还窄
主版本为 0 是 SemVer 明确定义的「不稳定阶段」，minor 升级即视为 breaking。所以 ^0.5.1 不是「大概兼容 0.5.x」，而是数学上严格限制在 >=0.5.1 —— 它比你直觉认为的更保守。
更危险的是 ^0.0.1：它几乎等于锁定，只接受 0.0.1 本身，改第三位都算 breaking。长期卡在 0.x 的包（比如内部 SDK 或新兴组件），不能靠 ^ 自动兜底。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 查 CHANGELOG 或 issue，确认
0.5.3 → 0.5.4是否删了你用的 public 方法 -
composer update --dry-run必须盯住 0.x 包的升级路径 - 别信包名数字小就“安全”，
0.25.0和0.26.0之间可能有 API 断层
约束交集为空时 Composer 不会“妥协”
^1.25.0 和 ~2.8.0 没有数学交集：^1.25.0 最高到 1.99.99，~2.8.0 最低从 2.8.0 起 —— 中间是断层。Composer 不会选个“差不多”的版本，它直接判定无解。
常见误操作是看到冲突报错就去删包，其实该找的是两个约束共同覆盖的版本。比如 monolog/monolog:2.9.3 同时满足 ^2.0 和 >=2.8.0，但若一个包硬写 ^1.25.0、另一个写 ^2.10.0，就真没交集。
- 用 Packagist 查目标包所有 tag，手动找落在重叠区的版本
- 避免写
"monolog/monolog": "^1.25 || ^2.10"—— 这等于放弃控制，API 兼容性由你代码承担 -
!=2.3.0这类排除式约束会拖慢 SAT 求解器，优先用^或~替代
composer.lock 永远比 composer.json 优先
你改了 composer.json 里的 "monolog/monolog": "^3.0"，但 composer.lock 里还记着 2.10.0，那 composer install 就只会装 2.10.0。这不是 bug，是设计。
想强制按新约束走？删掉 composer.lock 再 composer install —— 但团队协作中慎用，会破坏一致性。只想更新单个包？用 composer update monolog/monolog --with-dependencies，它只重算该包及其直系依赖，不会把 laravel/framework 从 v10.32 卷到 v10.33。
- 执行后立刻
git diff composer.lock，确认只有预期改动 -
composer show输出带*（如3.5.0 *）说明该包未被显式锁死，可能来自间接依赖 - 私有 SDK、内部组件才是高频冲突源，
composer why-not vendor/pkg要从最后一行（你的composer.json）往上逆推
