^1.2.3允许升至1.99.999但绝不升级到2.0.0，其核心是按semver主版本锚定，假设主版本变更即不兼容；开发中误用"dev-main"会导致线上版本不可控，正确做法是上线前替换为稳定tag或commit hash，且最终生效的是composer.lock而非composer.json中的符号。
^1.2.3 允许升到 1.99.999，但绝不会到 2.0.0
这是 ^ 的核心行为：它按语义化版本（SemVer）的主版本（MAJOR）锚定，假设包作者严格遵守“主版本变更 = 不兼容”。所以 ^1.2.3 等价于 >=1.2.3 ，允许所有 <code>1.x.y 中满足条件的最新版本——包括 1.10.5、1.99.0，哪怕中间跳了十几个 minor 版本。
常见错误现象：
- 本地装着
guzzlehttp/guzzle1.5.0，composer update后变成1.12.0，结果某个请求头处理逻辑静默变更，API 调用开始失败 - 写了
^1.0却以为只锁在1.0.x，实际可能拉到1.9.9
适用场景：
- 依赖主流生态包（如
symfony/console、monolog/monolog），且其 CHANGELOG 明确标注 breaking change - 项目有完整测试覆盖 + CI 自动验证，能及时捕获 minor 升级引入的行为差异
注意边界：^0.2.3 在 0.x 阶段不等同于 ^1.2.3 —— 它退化为 >=0.2.3 ，仅放开 patch 升级。这不是“更保守”，而是 SemVer 对 0.x 的定义：不稳定阶段，任何 minor 变更都可能破坏兼容性。
~1.2.3 只允许升到 1.2.999，连 1.3.0 都被拦住
~ 的锚点不是主版本，而是“最左侧非零段”。对 ~1.2.3 来说，最左侧非零段是 1（主版本），但它真正锁定的是 1.2 这个次版本组合，所以等价于 >=1.2.3 。它不管作者是否守 SemVer，只机械执行“前两位不变，第三位任意增长”。
常见错误现象：
- 写
"acme/sdk": "~1.2.3"，但该包最新版是1.2.2或1.3.0，composer install直接报错“no matching package found” - 误以为
~1.2和~1.2.0有区别——其实两者都等价于>=1.2.0
适用场景：
- 集成银行/支付类 SDK，文档缺失、发布无规律，minor 版本常含隐式 breaking change
- 老系统维护，已验证仅
2.4.x与现有代码完全兼容，不敢冒任何风险
性能提示：范围越窄，Composer 解析依赖树越快，冲突提示也越早出现。对超大项目，~ 能减少 resolver 的搜索空间。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
0.x 版本下 ^ 和 ~ 行为一致，但逻辑完全相反
表面看 ^0.5.2 和 ~0.5.2 都等价于 >=0.5.2 ，容易让人以为“它们只是写法不同”。实际上：
-
^0.5.2是因为 SemVer 规定：主版本为 0 时，**任何 minor 升级都不保证兼容**，所以^主动收缩为只允许 patch 升级 -
~0.5.2是因为“最左侧非零段”是5（位于第二位），所以锚点落在次版本，自然卡在0.5.x
这个差异在 ^0.0.3 vs ~0.0.3 时彻底暴露：
-
^0.0.3等价于>=0.0.3 → 实际只接受 <code>0.0.3（因为0.0.4还没发布，且0.1.0已越界） -
~0.0.3等价于>=0.0.3 → 只要 <code>0.0.4、0.0.99存在，就全允许
所以别凭经验猜；运行 composer show -s vendor/package 查看实际解析出的约束范围，比读文档更可靠。
dev-main 不能和 ^/~ 混用，上线前必须替换
dev-main、dev-develop 是分支别名，不是版本号。^ 和 ~ 对它们完全无效——Composer 不会去比较 “dev-main 是否 >=1.2.3”，而是直接忽略约束或报错。
常见错误做法：
- 开发时写
"monolog/monolog": "dev-main"，觉得“最新就是最好” - 上线前忘记改，导致每次
composer install拉下的代码完全不可控
正确做法：
- 开发阶段临时使用，但必须加注释说明用途，例如：
// dev-main: testing async log flush, remove before prod - 上线前替换成稳定 tag，如
"monolog/monolog": "^3.5"，或指定 commit hash："monolog/monolog": "dev-main#abc123" - 若真需长期跟踪某分支，用
"monolog/monolog": "dev-main as 3.99.99"并调低minimum-stability，但依然不推荐用于生产
真正决定线上跑哪个版本的，永远是 composer.lock，不是 composer.json 里的符号。符号只在 composer update 时起作用；lock 文件一旦存在，install 就只认它。
