^1.2.3 实际允许升至 1.99.999，等价于 >=1.2.3 =1.2.0 =0.2.3
^1.2.3 实际允许升到 1.99.999，不是“只升小版本”
很多人看到 ^1.2.3 就以为它只允许升到 1.2.x 或最多 1.3.x，这是错的。^1.2.3 等价于 >=1.2.3 ，意味着只要主版本还是 1，哪怕 <code>1.99.999 也合法。Composer 不会拦着它——除非包作者自己没发那么高的版本。
常见错误现象：composer update 后 some/package 从 1.5.0 跳到 1.12.0，接口行为突变、测试挂掉。这不是 Composer 失控，而是你高估了包对 SemVer 的遵守程度。
-
^的锚点是主版本（MAJOR），它假设作者在 MINOR 升级里不破坏 API - 如果包的 CHANGELOG 里频繁出现 “BREAKING: …” 在 1.x 内，
^1.2.3就等于开盲盒 - 用
composer show -s vendor/package查看当前约束实际解析出的上下界，比凭印象更可靠
~1.2.3 只放行 PATCH 升级，MINOR 被锁死
~1.2.3 看似宽松，其实极窄：它等价于 >=1.2.3 ，连 <code>1.3.0 都不允许，更别说 1.10.0。它的锚点不是主版本，而是“最左侧非零段”——这里就是第二位的 2，所以只放开第三位（PATCH）。
常见错误现象：写 "vendor/pkg": "~1.2.3"，结果 composer install 报错“no matching version”，因为该包最新版是 1.2.2 或 1.3.0，都不在 >=1.2.3 范围内。
-
~1.2等价于~1.2.0，即>=1.2.0 ；但 <code>~1.2.3明确要求最低 PATCH 是 3 - 它适合已验证仅
1.2.x安全的老系统，或某次升级后发现1.3.0引入隐式兼容问题 - 范围越窄，Composer 解析越快，冲突提示也越早——但这不等于更“安全”，只是把风险显性化了
0.x 版本下 ^ 和 ~ 表面一致，逻辑完全不同
^0.2.3 和 ~0.2.3 都等价于 >=0.2.3 ，但原因相反：<code>^ 因为 SemVer 规定 0.x 是不稳定阶段，主动降级为只允许 PATCH 升级；~ 则是因为最左侧非零段是第二位（2），自然卡在 0.2.x。
一旦换成 ^0.0.3 vs ~0.0.3，差异立刻暴露：^0.0.3 锁死到 0.0.3（不接受任何更新），而 ~0.0.3 允许升到 0.0.999。
- 别因表面结果相同就混用——它们背后依赖的假设不同，迁移或调试时容易误判
- 0.x 包默认就不该用
^放任 MINOR 升级，哪怕它看起来“更现代” - 真要用 0.x 包，优先查文档是否承诺稳定性；否则直接写死版本，比如
"vendor/pkg": "0.2.3"
dev-main 这类分支别名完全不参与 ^/~ 计算
"monolog/monolog": "dev-main" 看起来方便，但它根本不在语义化版本体系里。Composer 不会把它和 ^ 或 ~ 做任何比较——求解器只按 commit hash 匹配，^ 和 ~ 对它无效，甚至可能报错或静默忽略。
常见错误现象：CI 构建结果每次都不一样，线上突然崩溃；composer.lock 里记录的是哈希值，但下次 composer update 拉下的代码可能完全不同。
- 生产环境必须避免
dev-前缀，包括dev-master、dev-develop - 真要跟踪开发分支，应改用
"monolog/monolog": "dev-main as 2.99.99"并调低minimum-stability，但仍不推荐 - 上线前务必替换为稳定标签，比如
"monolog/monolog": "^3.5"或精确哈希"dev-main#abc123"
composer show vendor/pkg 的输出，比背 ^ 和 ~ 的数学定义管用得多。
