^1.2 表示 >=1.2.0 且 =1.2.3 且
Composer版本约束不是“指定要装哪个版本”，而是“声明哪些版本可被接受”——它参与全局逻辑求解，最终选中的版本必须同时满足所有直接和间接依赖的约束，一个都不能漏。
^1.2 和 ~1.2.3 到底差在哪？
这两个符号看起来都“允许升级”，但升级边界完全不同，误用会导致意外降级或卡死在旧版。
-
^1.2等价于>=1.2 ：允许次版本（1.3、1.4）和补丁版本（1.2.1、1.2.15）更新，只要不跨主版本。适合大多数生产依赖。 -
~1.2.3等价于>=1.2.3 ：只允许补丁版本更新（1.2.4、1.2.20），连 1.3.0 都不允许。常用于对小版本变更敏感的底层库（如序列化格式有变动时）。 - 常见错误：把 Laravel 写成
"laravel/framework": "~10.0"→ 实际锁死在10.0.x，错过所有10.1+的安全修复，且composer update不会动它。
为什么写死了 "1.2.3" 还是装了 1.2.5？
你没写错，但 Composer 没按字面执行——"package": "1.2.3" 是精确约束，但前提是该版本存在且无冲突；一旦它被某个间接依赖的 conflict 排除，或 PHP 版本不兼容，Composer 就会回退到下一个满足全部条件的版本（比如 1.2.5），甚至报错。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 检查实际安装版本：
composer show vendor/package，看输出的versions行是否含1.2.3。 - 查谁拦路：
composer prohibits vendor/package:1.2.3，它会列出所有阻止该版本被选中的包及其约束。 - 强制锁定（慎用）：
composer require vendor/package:1.2.3 --no-update+ 手动编辑composer.lock中对应条目的version和dist.shasum，再composer install。
多个约束并存时，交集才是真范围
你在 require 里写 "monolog/monolog": "^2.0"，又在 conflict 里写 "monolog/monolog": "，那最终可选范围就是 <code>>=2.0 && ——不是“先装再踢”，而是从一开始就不考虑 2.9.0+ 的任何版本。
- 这种组合常用于规避已知 bug 版本，比如某版 Guzzle 在 PHP 8.3 下崩溃，就加
"guzzlehttp/guzzle": " 到 <code>conflict。 - 注意
conflict不会触发自动降级：如果当前 lock 文件里已是 7.8.1，composer install仍会失败，必须composer update guzzlehttp/guzzle才会重新求解。 - 别指望
require-dev里的约束影响生产环境：composer install --no-dev会完全忽略require-dev中的所有约束，包括它们带进来的间接依赖。
真正容易被忽略的是：Composer 解析时根本不管 composer.json 里 require 的书写顺序，也不管你是手动写还是 composer require 自动生成的——所有约束扁平摊开，由 SAT 求解器统一建模。所以看到 Your requirements could not be resolved，第一反应不该是“改写法”，而是用 composer why-not 和 composer prohibits 去挖那个藏在三层依赖之后的冲突源。
