~1.2.3 等价于 >=1.2.3 =1.2.3
~1.2.3 和 ^1.2.3 解析结果完全不同
波浪号 ~ 和折音号 ^ 都是 Composer 的版本约束操作符，但它们的“兼容边界”定义不同，直接决定你最终装到哪个版本。
~1.2.3 等价于 >=1.2.3 ：只允许补丁级更新（<code>1.2.4、1.2.99），拒绝任何次版本升级（1.3.0 起全被拦）。
^1.2.3 等价于 >=1.2.3 ：允许所有次版本和补丁升级（<code>1.3.0、1.9.9 都合法），只要不跨主版本。
关键区别就在这里：~ 锁定的是「最后一位数字的向上范围」，^ 锁定的是「主版本不变的向下兼容范围」。
-
~1.2会被 Composer 自动补全为~1.2.0，即>=1.2.0 -
^1.2同样被补全为^1.2.0，即>=1.2.0 -
~1≡>=1.0.0 ，和 <code>^1表现一致；但这是特例，不是通则
什么时候该用 ~，什么时候该用 ^
选哪个，取决于你对依赖稳定性的容忍度和语义化版本（SemVer）实践的严格程度。
用 ~ 的典型场景：
- 你明确知道某个次版本（如
1.2.x）存在未修复的兼容性问题，但1.2.3是最后一个可用的稳定点 - 团队 CI 流水线要求最小可变范围，避免因
1.2.9→1.3.0引入意外行为 - 你在维护一个长期运行的遗留项目，升级次版本需人工验证
用 ^ 的典型场景：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 你信任上游遵循 SemVer，且希望自动获得安全补丁和小功能改进（如 Laravel 官方推荐
^10.0） - 项目处于快速迭代期，需要频繁同步依赖的 bugfix，但又不想手动 bump 每个补丁号
- 你使用的是现代框架生态（如 Symfony、Monolog），其发布策略与
^天然匹配
~1.2 和 ~1.2.0 看似一样，实际有坑
表面上 ~1.2 会自动转成 ~1.2.0，行为一致。但问题出在解析时机和 Composer 版本差异上。
Composer 1.x 和 2.x 对隐式补全的处理逻辑略有不同；某些旧版（尤其是 1.10 之前）在解析 ~1.2 时可能产生歧义或缓存残留。
更现实的风险来自协作环境：
- 有人本地用 Composer 2.5，写
~1.2→ 解析为>=1.2.0 - CI 机器上跑的是 Composer 1.8，同一行可能被误判为
>=1.2.0 （极少数边缘 case） - Git 提交的
composer.lock里记录的版本哈希，可能因此对应不同源码
解决办法很简单：显式写三位，比如 ~1.2.5 或 ^1.2.5，杜绝任何补全猜测。
镜像源不会改变 ~ 和 ^ 的行为，但会影响“能拿到哪些版本”
镜像只是包元数据和 zip 包的代理通道，~1.2.3 的约束逻辑永远由 Composer 本地解析，和你用的是阿里云还是 packagist.org 无关。
但真实世界里，你会遇到这些情况：
- 上游刚打了
v1.2.4tag，阿里云镜像延迟 2 分钟才同步 →composer update找不到1.2.4，只能回退到1.2.3，看起来像“没升级”，其实是镜像滞后 - 你配置了
"packagist.org": false但镜像 URL 少了个/（如写成https://mirrors.aliyun.com/composer）→ Composer 拼出错误路径，静默 fallback 到官方源，导致部分包走官方、部分走镜像，~和^约束仍生效，但来源不一致 -
composer clear-cache必须在update前执行，否则本地缓存的旧元数据会让 Composer 认为“1.2.4不存在”，哪怕镜像里已有
真正影响锁定效果的，从来不是镜像本身，而是你有没有让 Composer 看到最新、最一致的版本列表。
