^锚定主版本号，~锚定次版本号；^2.8.0等价于>=2.8.0 =2.8.0 =0.8.2

别信“^是宽松、~是严格”这种说法——它俩锚点不同，不是松紧问题，是坐标系错位。 写错一个符号，下次 composer update 就可能把破坏性变更直接拉进生产环境。

^ 和 ~ 的锚点到底卡在哪一位？

它们不看“你感觉多宽松”，只按 SemVer 三位数字做数学截断：

• ^2.8.0 锚定主版本 2，等价于 >=2.8.0 —— 次版本能升到 <code>2.99.0，但绝不会跨 3.0.0
• ~2.8.0 锚定最左侧非零段 2.8，等价于 >=2.8.0 —— 连 <code>2.9.0 都不放行，只允许修订号变（2.8.1、2.8.99）
• ~2.8 和 ~2.8.0 完全等价；^2.8 和 ^2.8.0 也完全等价 —— Composer 会自动补 .0，手写漏掉第三位容易误读
• ^0.8.2 在 0.x 下行为突变：等价于 >=0.8.2 ，不是 <code> —— 因为 SemVer 规定 0.x 中 minor 升级即视为 breaking

为什么生产环境常写 ~2.7.4 而不是 ^2.7.4？

这不是风格偏好，是兼容性命门：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 某支付 SDK 明确只测过 monolog/monolog 的 2.7.x 系列，但 ^2.7.4 在 CI 构建时悄悄拉了 2.8.0，结果日志格式变更导致对账失败
• ~2.7.4 能守住 2.7.x，既避开 2.8.0 的接口变动，又拿到 2.7.5 的内存泄漏修复
• ~ 不识别 CVE，也不区分“安全补丁”和“新功能”——它只机械截断。真要管漏洞，得靠 composer audit，不是靠符号

装不上指定版本？先查真实 tag，别只盯 composer.json

Could not find a matching version? 很大概率不是约束写错，而是远程没这个 tag：

• 运行 composer show monolog/monolog --all，它列出所有真实存在的 tagged release（如 3.5.0、2.10.0）、预发布（3.6.0-RC1）、分支快照（dev-main）
• 本地打了 git tag v1.2.3 但没 git push origin v1.2.3 → Packagist 同步不到
• 用了带注释的 tag（git tag -a v1.2.3 -m "release"）→ 某些旧版 Packagist 解析失败
• Tag 名含非法字符（v1.2.3+build、v1.2.3-beta）→ Packagist 跳过该 tag

composer.lock 永远比 composer.json 优先

这是最常被忽略的执行逻辑：

• 把 "monolog/monolog": "^2.0" 改成 "^3.0"，但 composer.lock 里还是 2.10.0 → composer install 仍装 2.10.0
• 想强制按新约束重装？删 composer.lock 再 composer install（慎用，影响团队一致性）
• 只想更新单个包？用 composer update monolog/monolog，它会重新计算依赖图并更新 lock
• 本地怀疑版本不对？直接跑 composer show monolog/monolog，它读的是 vendor/ 下真实安装的版本，比看 composer.json 更可靠

真正难的不是记住符号规则，而是每次 composer update --dry-run 都得盯着输出确认升级范围是否落在你预期的区间内——尤其当依赖链里混着 0.x 包时，一个 ^ 可能比你想象中窄得多。