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 Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（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 不够，得靠集成测试覆盖实际路径。