直接结论：别用"vendor/sdk": "2.9"，它等价于锁死2.9.0.0且不兼容补丁；应使用~2.9.0（>=2.9.0，限2.9.x）或>=2.9（明确灰度起始线），并确保root package收紧约束、下游包声明兼容，配合分支+lock+ci实现隔离灰度。
怎么写版本约束才能让SDK升级不崩
直接结论：别用"vendor/sdk": "2.9"这种写法，它等于锁死2.9.0.0，既不兼容补丁更新，又可能被其他包拖进不兼容大版本。真正可控的灰度起点是明确边界。
-
~2.9.0→ 实际等价于>=2.9.0 ，只允许补丁级更新，适合强锁定灰度范围 -
^2.9→ 允许2.9.x到2.999.999，但不会进3.0；注意^0.9和^1.9行为不同，前者不进0.10 -
>=2.9→ 最直白，无歧义，推荐用于定义灰度起始线；它不设上限，但依赖图会自动收束到最高兼容版本
为什么composer update总跳过你想试的SDK版本
不是 Composer 故意绕开你，而是整个依赖树在“投票”。某个下游包（比如phpunit/phpunit或laravel/framework）可能硬性要求guzzlehttp/guzzle:^7.0，而你想升的 SDK 依赖^8.0，结果 Composer 只能妥协回退。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 查谁在拉低版本：
composer depends guzzlehttp/guzzle列出所有依赖它的包及其约束 - 看当前装了啥：
composer show guzzlehttp/guzzle确认真实安装版本 - 关键点：灰度必须从 root package（你的项目）开始收紧约束，并确保关键依赖已声明对新 SDK 版本的兼容（比如它们的
composer.json里写了"require": {"vendor/sdk": "^2.9"}）
灰度环境怎么避免影响生产镜像
Composer 没有environment: production字段，但你可以靠分支 + lock 文件 + CI 步骤组合出效果。灰度分支和主干的composer.lock必须不同，且不能混用。
- 灰度分支的
composer.json用宽松约束，例如"vendor/sdk": "^2.9"；主干/生产分支则锁死"vendor/sdk": "2.9.1" - CI 构建生产镜像时，必须加
--no-dev --no-interaction，强制只按 lock 文件还原，不被composer.json干扰 - 灰度环境 CI 可跑：
composer update vendor/sdk --with-dependencies，而不是全量update，避免意外带进其他变更 - 别信
require-dev能帮你灰度——dev 包默认不安装，线上根本不会加载
SDK升级后接口行为突变，怎么快速定位断层
升级后报Call to undefined method或返回空、404，大概率不是网络问题，而是 SDK 内部契约变了。CHANGELOG 不是可选读物，是必查项。
- 先查
CHANGELOG.md里的Breaking Changes小节：类名是否改了？方法签名是否删了？Client::send()是否变成Client::request()？ - 留意默认行为变更：老版可能自动重试 3 次，新版默认关掉，结果线上突然大量
Connection refused - 认证头是否变：有些 SDK 默认发
Bearer，但新接口实际要API-Key，得显式传headers => ['API-Key' => 'xxx'] - base_uri 是否错位：文档写
https://api.example.com，实际要https://api.example.com/v2/，漏掉/v2/就 404
composer.lock一旦生成，就必须提交，且不能和主干共用——它不是副产品，是灰度策略本身。
