结论：版本号符号决定依赖行为，2.0被解析为精确版2.0.0，不兼容2.1.3；^2.0才允许小版本升级，等价于>=2.0.0
直接说结论：版本号不是随便写的，^、~、精确版本（如 5.0.0）行为完全不同，写错一个符号就可能让 Composer 拒绝安装、降级失败，甚至拉下整个依赖树的旧版。
为什么 composer require vendor/pkg:2.0 没装上预期版本？
Composer 默认把不带运算符的数字（如 2.0）解析为「精确版本」2.0.0，而非「兼容 2.x 最新版」。如果项目里已有 vendor/pkg 的 2.1.3（被其他包引入），Composer 就会拒绝降级——它不会主动卸载已存在的更高版本。
- 想允许小版本升级（推荐日常使用）：写
^2.0，等价于>=2.0.0 - 想只允许补丁级升级：写
~2.0，等价于>=2.0.0 - 必须锁定某次发布（如修复了关键 bug）：写完整版本
2.0.7，不加任何前缀 -
2.0.*是合法写法，但和^2.0行为不同：2.0.*只匹配2.0.x，不包括2.1.0；而^2.0包含所有2.x
运行 composer require 后 composer show vendor/pkg 显示的版本还是旧的？
常见于本地已有该包（比如之前通过其他依赖间接装过），而你这次指定的版本比它还低。Composer 不会自动降级已存在包，除非你显式触发重算。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先确认当前实际安装版本：
composer show vendor/pkg - 检查是否被其他依赖锁定：
composer depends vendor/pkg - 强制按新约束重装：运行
composer update vendor/pkg（注意不是install） - 如果仍失败，可能是
composer.lock锁定了旧版——删掉它再跑composer install，但要小心影响其他包
怎么查某个包最新 stable 版本该用什么写法？
别猜，去 Packagist 页面看。比如访问 https://packagist.org/packages/monolog/monolog，顶部会显示 latest stable tag（如 v3.5.0），再决定用 ^3.5 还是 ^3.0。
- 如果包主遵循语义化版本（绝大多数主流包都遵守），优先用
^x.y - 如果包更新频繁且不保证兼容性（比如某些 dev-only SDK），考虑用
dev-main或dev-master，但生产环境慎用 - 阿里云 VIAPI 的 PHP SDK（如
alibabacloud/facebody-20191230）通常按日期发版，这时应写精确版本或^20191230.0类写法，避免意外升级到不兼容的新日期版
最常被忽略的一点：版本约束生效的前提是 composer.json 被真正写入并参与依赖解析。手动改完 JSON 后，记得运行 composer dump-autoload（如果只是改 autoload 配置）或 composer update（如果改了 require）——否则改了也白改。
