^锚定主版本，~锚定最左侧非零段：^2.8.0等价于>=2.8.0 <3.0.0，~2.8.0等价于>=2.8.0 <2.9.0，~0.5.1等价于>=0.5.1 <0.6.0，~0.3.4等价于>=0.3.4 <0.4.0。
Composer 的版本约束不是“选最新”，而是按 SemVer 规则算出一个数学上合法的区间；写错一个符号，就可能把破坏性变更直接拉进生产环境。
^ 和 ~ 的锚点逻辑完全不同，别凭感觉猜范围
很多人以为 ^ 是“宽松”、~ 是“严格”，其实它们根本不在同一套坐标系里：^ 锚定主版本（M），~ 锚定最左侧非零段（可能是 M，也可能是 M.N）。
-
^2.8.0→ 等价于>=2.8.0 ：允许升到 <code>2.99.99，只要主版本还是 2 -
~2.8.0→ 等价于>=2.8.0 ：次版本卡死在 <code>2.8.x，连2.9.0都不放行 -
^0.5.1→ 等价于>=0.5.1 ：0.x 下次版本变动即视为不兼容，所以 <code>^主动收紧 -
~0.3.4→ 等价于>=0.3.4 ：锚在 <code>0.3，不是0
常见错误是把 ~2.8 当成 ~2.8.0，其实它等价于 ~2.8.0，但手写时漏掉第三位容易引发误读；更危险的是写成 ^2，本意是“2.x 就行”，结果它真会装 2.99.99 —— 而你根本没测过那个版本。
0.x 包的 ^ 约束比你以为的更窄，不是“还没稳定”，是“随时可能崩”
0.x 不是客气话，是 SemVer 明确定义的「不稳定开发阶段」。这意味着 ^0.5.1 实际只允许 0.5.x，哪怕包作者发了 0.6.0，也属于不兼容变更 —— Composer 会拦住，不是它保守，是规则如此。
-
^0.0.1几乎等于锁定：只匹配0.0.1本身，改第三位都算 breaking - 长期卡在 0.x 的包（比如某些新兴组件或内部工具库），不能只看数字，得查它的
CHANGELOG或 issue，确认是否真守 SemVer - 如果依赖链里有 0.x 包，
composer update --dry-run必须重点盯：它可能悄悄把0.5.3 → 0.5.4，而后者删了一个你正在用的public方法
这不是 Composer 的 bug，是它在严格执行规范。你写的 ^0.5.1，它就只敢给你 0.5.x；你指望它自动跨 0.5 → 0.6，它不会干。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer.lock 永远比 composer.json 优先，版本不一致？先看 lock 文件
composer install 装的版本和 composer show 显示的不一样？大概率不是 Composer 算错了，是 composer.lock 在起作用 —— 它的优先级永远高于 composer.json 中的约束。
- 哪怕你把
monolog/monolog改成"^3.0"，只要 lock 文件里还记着2.10.0，install就只会装那个 - 想强制按新约束重装？删掉
composer.lock再composer install（慎用，影响团队一致性） - 只想更新某一个包？用
composer update vendor/package，它会重新计算依赖图并更新 lock -
composer show输出里版本号带*（如3.5.0 *），说明该包不在 lock 文件中，可能是被其他包间接引入、且未被显式约束
很多“版本没更新”的问题，本质是忘了 composer update 后要提交新的 composer.lock —— 不提交，别人 install 时就永远拿不到你的新约束。
PHP 版本冲突报错太模糊？用 composer why-not 定位卡点
当 composer require 报错 Your requirements could not be resolved to an installable set of packages.，真实原因往往不是你的写法错，而是某个依赖的 require 段写了 "php": "^8.1"，而你本地是 PHP 8.0 —— 但 Composer 不会直接告诉你谁写的这个限制。
- 用
composer why-not php:8.0可以列出所有阻止升级到 PHP 8.0 的包及其约束条件 - 同理，
composer why-not vendor/package:2.0能查清为什么装不上某个特定版本 - 这类命令依赖 lock 文件存在；如果刚初始化项目还没 lock，先
composer install --no-scripts生成基础 lock 再试 - 私有包查不到版本？检查
repositories配置是否正确、token 是否有效，镜像源可能延迟数小时
真正关键的不是记住 ^ 和 ~ 的换算表，而是理解：Composer 的版本决策永远基于三个事实——你写的约束、包声明的 version、它是否真守 SemVer。三者缺一不可。一旦其中一环松动，再严谨的约束也没用。
