^1.2.3 本身不会升到 2.0.0，它严格等价于 >=1.2.3 且 <2.0.0；问题常源于传递依赖的宽松约束（如 "^1.0 || ^2.0"）迫使 Composer 为满足整体依赖图而选择 2.0.0 版本。
composer update 本身不决定兼容性，真正起作用的是你写的版本约束符——写错一个符号，就可能在下次更新时把 ^1.2.3 升成 2.0.0，而你的代码里还用着已被移除的 SomeClass::oldMethod()。
为什么 ^1.2.3 有时会升到 2.0.0？
它不会。但你可能混淆了「根依赖约束」和「传递依赖的实际解」：^1.2.3 确实只允许 1.x；问题常出在上游包自己写了宽泛约束，比如 "monolog/monolog": "^1.0 || ^2.0"，而你的项目又同时 require 了另一个需要 monolog:^2.0 的包——Composer 为满足整体依赖图，会把你的 ^1.2.3 “解释”成可接受 2.0.0（只要它也满足 ^1.2.3 的“语法假象”，实际已越界）。
- 检查
composer.lock中该包的真实安装版本，别只信composer.json里的写法 - 运行
composer show monolog/monolog看它声明的require列表，确认是否引入了跨主版本的宽松依赖 - 用
composer prohibits monolog/monolog:2.0.0查谁在阻止升级，反过来也能发现谁在“偷偷拉高”
~ 和 ^ 在 API 兼容性上到底差在哪？
~1.2.3 表示 >=1.2.3 && <1.3.0，连 1.2.99 都行，但绝不会碰 1.3.0；^1.2.3 是 >=1.2.3 && <2.0.0，允许所有 1.x 小版本和补丁升级。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 如果你的业务强依赖某个次版本的行为（比如 Laravel 的
10.28修复了队列重试逻辑），用~10.28.0比^10.0更稳 -
^更适合工具类库（如symfony/console），它们通常严格守 SemVer，小版本新增对你无害 -
~0.2.3实际等价于>=0.2.3 && <0.3.0，而^0.2.3只锁0.2.x—— 两者在 0.x 阶段行为一致，但语义不同：前者强调“最小兼容”，后者强调“主版本不变”
升级后报 TypeError 或 Class not found 怎么快速定位？
这些不是 Composer 的错，而是版本约束失效后暴露的底层不兼容。重点不是看 composer update 输出了什么，而是看运行时哪里崩了：
- 先跑一遍完整测试：
vendor/bin/phpunit，对比升级前后的失败用例 diff - 关注
TypeError、ArgumentCountError、Deprecated（PHP 8.1+ 默认转异常） - 检查返回值类型变化：比如某方法从
array改成Illuminate\Support\Collection，但你用了count()或array_keys() - 执行
composer dump-autoload --optimize后，必须清空 OPCache（opcache_reset()或重启 PHP-FPM），否则 autoload 映射还是旧的
开发 SDK 类包时，version 字段根本不管 API 兼容性
composer.json 里的 "version": "2.5.1" 只影响包管理器如何解析依赖，跟你的 HTTP 请求发的是 /v2/ 还是 /v3/ 完全无关。
- API 版本应通过构造参数、请求头（
Accept: application/vnd.acme.v2+json）或 URL 路径显式控制 - 在
extra字段里加自定义声明："extra": {"api-version-range": ">= v2.0, ，方便下游判断适配性 - 不要指望用户靠看 SDK 版本号来推断后端 API 版本——他们很可能搞错，尤其当 SDK 自身做了多版本路由转发时
config.platform.php 被忽略导致本地能装、CI 直接挂。 
