composer outdated 默认不标主版本升级，因其仅比对满足 composer.json 版本约束的最新稳定版（如 "^2.8" 不匹配 v3.0.0），而主版本跃迁被 SemVer 定义为潜在破坏性变更，Composer 为防崩溃默认排除；需加 --all 强制显示并人工识别主版本号变化及 ! 警告。
composer outdated 为什么默认不标出主版本升级
因为 composer outdated 的判断逻辑完全基于你 composer.json 中写的版本约束，而不是 Packagist 上的绝对最新版。比如你写的是 "monolog/monolog": "^2.8"，那它只关心“满足 ^2.8 的最高稳定版”——而 v3.0.0 不满足这个约束，根本不会进入比对范围，自然也不会出现在输出里。
这种设计不是疏漏，是 SemVer 和 Composer 协同工作的前提：主版本变更（2.x → 3.x）被语义化版本规范明确定义为可能含破坏性变更，Composer 默认拒绝跨主版本自动匹配，避免意外升级导致运行时崩溃。
常见错误现象：outdated 没列出 laravel/framework 的 v11，但你知道它已发布——大概率是你 composer.json 里锁着 "^10.0" 或更窄的约束，v11 不在允许范围内。
怎样让 outdated 显式暴露主版本跃迁风险
加 --all 参数强制拉取所有已安装包的最新可用版本（含超出当前约束的），再人工识别主版本号变化：
-
composer outdated --all --direct --no-dev：聚焦你亲手声明的依赖，排除 dev 工具和传递依赖干扰 - 重点关注第三列（latest）和第二列（installed）的主版本号是否不同，例如
symfony/http-foundation v6.4.7 → v7.0.0 - 带
!号的行（如doctrine/orm 2.15.3 → 3.0.0 !）是明确警告，通常对应文档中已标注 breaking changes 的发布
注意：--all 会把预发布版（RC/beta）也列出来，若你设了 "minimum-stability": "stable"，这些版本实际不会被 update 拉取，但它们的主版本号仍值得警惕——说明正式版可能已在路上。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
主版本升级前必须验证的三件事
仅看版本号不够，SemVer 只是约定，不是银弹。真实破坏性往往藏在细节里：
- 查该包的
CHANGELOG.md或 GitHub Release 页面，搜索BC break、deprecated、removed等关键词 - 运行
composer update vendor/package --dry-run，观察是否报your requirements could not be resolved——这常意味着 PHP 版本、扩展依赖或与其他包的冲突已实际存在 - 确认你的 PHP 运行环境兼容：Laravel 10 要求 PHP ≥8.1，Symfony 7 要求 ≥8.2，用
php -v和composer config platform.php对照检查
别跳过 --dry-run。很多团队在 CI 中看到 outdated 提示 v3.0.0，直接 update，结果测试全挂——问题就出在没跑这一步，漏掉了约束求解器发现的真实冲突。
小版本更新 ≠ 绝对安全，但主版本升级一定需要人工介入
^2.8 允许升到 2.99.99，看起来宽松，但次版本升级（2.8 → 2.15）也可能废弃你正在用的某个方法，只要它没改函数签名、没删类名，就符合 SemVer 定义的“兼容”。所以 outdated 标为 semver-safe-update 的包，只是“理论上可自动升”，不代表你代码里没调用即将废弃的 API。
真正危险的是主版本跃迁：v2.9.4 → v3.0.0。这个 3.0.0 不只是数字变大，它代表维护者主动声明“旧契约作废”，你代码里任何假设 v2 行为的地方都可能失效。这种升级无法靠工具全自动兜底，必须逐个验证调用点、更新文档、调整测试用例。
最易被忽略的一点：有些包的主版本升级不改类名或命名空间，但内部行为已变（比如缓存策略、异常抛出时机、默认配置值）。这时候光看 outdated 输出和 CHANGELOG 不够，得靠集成测试覆盖实际路径。
