~ 波浪号表示允许补丁级升级但禁止次版本升级，如 ~1.2.3 等价于 >=1.2.3 <1.3.0，~1.2 等价于 >=1.2.0 <2.0.0，~1 等价于 >=1.0.0 <2.0.0。
composer.json 里 ~ 波浪号到底匹配哪些版本
波浪号 ~ 是 Composer 最容易被误解的版本约束符——它不是“取近似值”，而是“允许补丁级升级，但不允许次版本升级”。比如 ~1.2.3 等价于 >=1.2.3 ，不是 <code>>=1.2.3 。
常见错误现象：~1.2 被误以为等同于 ^1.2；实际它等价于 >=1.2.0 （注意：末尾没写补丁号时，Composer 自动补 <code>.0）。
-
~1.2.3→ 允许安装1.2.3、1.2.4、1.2.99，但拒绝1.3.0 -
~1.2→ 等价于~1.2.0，即>=1.2.0 -
~1→ 等价于~1.0.0，即>=1.0.0 （这是唯一一次和 <code>^1行为一致）
什么时候该用 ~ 而不是 ^
用 ~ 的核心场景是：你明确依赖某个次版本的 API 行为，且知道补丁更新不会破坏它，但次版本升级（如 2.3 → 2.4）可能引入不兼容变更或行为调整——尤其在非语义化版本（如早期 Laravel 插件、私有包）中更常见。
对比 ^：^1.2.3 允许 1.9.9，但 ~1.2.3 只到 1.2.x。如果你的代码调用了 1.2 特有的内部方法，而 1.3 已移除，~ 就是更保守的选择。
- 私有公司包，版本号不遵循 SemVer，但补丁修复频繁 → 用
~ - 依赖某个框架的特定小版本插件（如
laravel-ide-helper ~12.4），新次版本已重构 API → 用~ - 标准开源库（如
guzzlehttp/guzzle），严格 SemVer → 优先用^
composer update 不按 ~ 约束升级？检查这三处
明明写了 "monolog/monolog": "~2.8.0"，运行 composer update 却装了 2.9.0？大概率不是约束失效，而是配置或缓存干扰。
- 检查
composer.lock是否存在且未被忽略——如果 lock 文件里已记录2.9.0，composer install会直接复用，无视composer.json新约束 - 确认没有全局
minimum-stability或prefer-stable: false配置，导致 Composer 拉取了预发布版（如2.9.0-beta） - 运行
composer update monolog/monolog --with-dependencies后，再查composer show monolog/monolog确认实际安装版本，避免被 IDE 缓存误导
混合约束写法的实际效果：比如 ~2.0 || ~3.0
这种写法合法，但容易高估它的灵活性。它表示“接受 2.x 的任意补丁版，或 3.x 的任意补丁版”，但不包括 2.9.0 和 3.0.0 之间的任何版本（比如 2.10.0 是有效的，但 3.0.0-alpha 不行，除非 stability 允许）。
真正要注意的是依赖图冲突：如果 A 包要求 ~2.0，B 包要求 ~3.0，而你同时 require 它们，Composer 会报错无法解决依赖——|| 是“或”关系，不是“兼容并包”。
-
"foo/bar": "~1.0 || ~2.0"→ 允许1.0.5或2.0.7，但不允许1.5.0（因为~1.0=>=1.0.0 ） - 想表达“1.x 或 2.x 全部”，应写
^1.0 || ^2.0，而非~ - 多个
||组合后，务必用composer prohibits vendor/package验证是否真能共存
波浪号的边界感很强，但它只管“本包版本范围”，不管依赖树里其他包怎么选——这点最容易被当成“安全网”，结果上线才发现间接依赖崩了。
