~1.2.3 等价于 >=1.2.3 =1.2.0 =1.0.0 =0.8.2
~1.2.3 等价于 >=1.2.3
很多人看到 ~1.2.3 就默认它只允许 1.2.4、1.2.99 这类补丁升级，其实这是错的——它真正锁的是“最右侧你写到的那一位”，也就是修订号（PATCH）层级。只要不跨过 1.3.0，哪怕 1.2.100 也合法。
-
~1.2.3→ 允许1.2.3到1.2.999，拒绝1.3.0及以上 -
~1.2会被 Composer 自动补全为~1.2.0，等价于>=1.2.0 -
~1则变成>=1.0.0 ，跨度极大，基本等于放行整个主版本
显式写三位（如 ~1.12.5）能避免不同 Composer 版本对隐式补全的解析差异，尤其在 CI/CD 流水线中更可靠。
~1.2 和 ~1.2.0 行为一致，但 ~1.2.0 更安全
表面上 ~1.2 和 ~1.2.0 都会锁死次版本为 2，但它们依赖 Composer 的自动补全逻辑。某些旧版 Composer（如 1.x 或早期 2.0.x）对 ~1.2 的补全可能不稳定，导致本地开发和 CI 装出不同版本。
- 团队协作时，
~1.2.0比~1.2更可预期 - CI 环境若使用 Docker 镜像预装 Composer，版本不统一时容易踩坑
- Git 提交
composer.lock能兜底，但前提是它没被忽略或误删
0.x 包下 ~ 行为不变，但语义风险更高
~0.8.2 仍等价于 >=0.8.2 ，但它掩盖了一个事实：0.x 版本没有“向下兼容新增功能”的承诺。哪怕只是 <code>0.8.3，也可能悄悄删掉一个方法。
- 别信
~0.8.2的“小版本安全”假象 - 遇到
spatie/laravel-ray:0.25.0这类包，必须查 CHANGELOG 或 issue 确认变更内容 - 生产环境建议直接用精确版本，如
"spatie/laravel-ray":"0.25.0"
波浪号只在 composer update 时起作用，install 完全无视
composer install 只读 composer.lock，里面记的是哈希和精确版本号，~ 在这时彻底失效。也就是说，改了 composer.json 里的 ~1.2.3 却没跑 composer update，vendor 里还是旧包。
- 部署脚本里漏掉
composer update或写成composer install --no-dev后忘记更新约束，就会锁不住 - 如果
composer.lock被 git 忽略或手动删除，composer install就退化为按当前镜像里“最新满足条件”的版本安装，~1.2.3可能真装上1.2.10 - 国内阿里云镜像偶尔延迟同步新 tag，
composer update时若找不到1.2.4，会 fallback 到1.2.3——这不是约束失效，是源没跟上
真正让 ~ 发挥作用的，是持续维护好 composer.lock 并确保每次 update 都在干净缓存下执行。
