波浪号允许在最后一位非零数字的下一级范围内升级：~1.2.3 表示 >=1.2.3 且 =1.2.0 且 =0.8.2 且
~ 波浪号到底允许多大范围升级？
它不是“差不多版本”，而是有明确数学边界的锁定策略：只允许在你写的最后一位非零数字的“下一级”里浮动。比如 ~1.2.3 表示 >=1.2.3 且 ；<code>~2.0 等价于 >=2.0.0 且 （注意：这里 <code>~2.0 的“倒数第二位”是 0，所以锁定的是 2.x 整个次版本系列）。
- 常见错误现象：写成
~1.2却以为能吃到1.3.0的新功能——实际不会，它卡死在1.2.x内 - 使用场景：你高度依赖某个包的内部行为（比如特定小版本的事件钩子顺序），又想自动获得 bug 修复，就用
~ - 参数差异：
~1.2.3≠~1.2：前者上限是1.3.0，后者上限是2.0.0，差一个次版本跨度
~ 和 ^ 插入号的区别，真不是“保守一点”而已
区别直接决定你装到哪个版本——可能隔一个小版本，也可能跳过整个兼容层。^1.2.3 允许升到 1.9.9，但 ~1.2.3 最多到 1.2.99；而 ^2.0.0 可升至 2.9.9，~2.0.0 同样只到 2.0.99。
- 常见错误现象：团队有人用
^、有人手写~，composer update后本地和 CI 装的包版本不一致，CI 构建失败 - 性能 / 兼容性影响：
~缩小了可选版本池，Composer 解析依赖图更快，也更少触发“无法满足所有约束”的冲突 - 0.x 版本要特别小心：
^0.8.2实际等价于>=0.8.2且，和 <code>~0.8.2行为一致——此时^自动降级为~级别，不是“更宽松”
什么时候该用 ~？别被“保守”误导
它不是给“怕升级的人”准备的默认选项，而是为明确知道“只有 patch 才安全”的场景设计的。比如你正在维护一个支付网关适配器，它强依赖 stripe/stripe-php 的 1.2.x 中某个未文档化的请求头处理逻辑，那 "stripe/stripe-php": "~1.2.5" 就比 "^1.2.5" 更靠谱。
- 使用场景：对接硬件 SDK、银行中间件、政府接口等更新极慢且变更不可测的依赖
- 容易踩的坑：把所有包都写成
~——结果半年后monolog/monolog还卡在2.2.x，错过大量日志上下文和结构化支持 - 实操建议：先查包的 CHANGELOG 或 GitHub Releases，确认它是否真按 SemVer 严格执行；如果作者常在 minor 版本里加 breaking change，
~才是救命稻草
composer.json 里写 ~，但 lock 文件没生效？
composer.lock 永远以实际安装版本为准，~ 只在 composer update 或首次 install 时起作用。如果你已锁定了 1.2.7，哪怕 composer.json 改成 ~1.2.3，只要不运行 update，就不会动。
- 常见错误现象：改了
~1.2.3后跑composer install，发现还是旧版——因为 lock 文件没更新，得composer update monolog/monolog显式触发 - 实操建议：CI 流水线必须用
composer install --no-interaction（读 lock），而非update；本地开发想尝鲜，再单独update某个包 - 关键点：
~是“下次更新时的许可范围”，不是“立刻拉最新”——这点和 npm 的~语义一致，但很多人误以为它会自动刷新
