应运行composer outdated --direct --minor-only定位主版本升级风险，输出中带→且左侧版本号跳变（如2.9.1→3.0.0）即为高危项；需结合官方changelog交叉验证废弃接口、配置变更等bc-breaking细节。

直接看变更日志比依赖解析更早发现兼容性风险——但必须结合 composer outdated 和包的官方 CHANGELOG 才有效，光跑命令不查文档等于没防。

怎么快速定位哪些包有主版本升级风险

运行 composer outdated --direct --minor-only 只显示直接依赖中发生次版本或主版本跳变的包（比如 monolog/monolog 从 2.9.1 → 3.0.0），输出里带 → 且左侧数字跳变的就是高危项。

• 别信 --all：它会把所有传递依赖都列出来，干扰判断；--direct 才是你能控制的范围
• 如果没输出，先检查 composer.json 是否设了 "minimum-stability": "stable"，临时删掉再试一次
• 某些包（如 phpunit/phpunit）在 require-dev 里，--direct 默认不包含，得加 --with-dependencies 或单独查 composer show phpunit/phpunit

为什么不能只靠 composer update --dry-run 预判破坏点

composer update --dry-run 只模拟依赖图计算，它完全不读 CHANGELOG，也看不到接口废弃、配置项移除、默认行为变更这些关键信息。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 它能告诉你 symfony/console 能否升到 v6，但不会提醒你 Application::setCatchExceptions() 已被移除
• 它不检查 PHP 扩展是否启用（比如新版本强制要求 ext-pdo_pgsql，但本地没装）
• 它不触发 post-update-cmd 脚本，而有些包（如 Laravel 的 php artisan vendor:publish）升级后必须手动重跑

查 CHANGELOG 的实操路径和常见陷阱

每个包的变更日志位置不统一，但优先按这个顺序找：

• 先看包主页 GitHub/GitLab 的 CHANGELOG.md 或 UPGRADE.md（例如 laravel/framework 的 UPGRADE.md）
• 没有就翻 releases 页面，重点看最新 tag 下的 Description，不是 Commits
• 若用 Packagist，点进包页右上角 Source 链接跳转源码库，别信第三方镜像站的摘要
• 警惕“BC breaks”藏在 Changed 或 Fixed 分类下——比如 guzzlehttp/guzzle v7.8.0 把 RequestOptions::SYNCHRONOUS 改成常量，但文档没标 BREAKING

升级前必须交叉验证的三处地方

光看 CHANGELOG 不够，要和本地代码对齐：

• 搜项目里所有 use 语句和 new 实例化，确认没调用已废弃类（如 Symfony\Component\HttpFoundation\Response 的 create() 方法在 v6.3 废弃）
• 检查配置文件中 key 名是否变更（monolog v3 把 channels 改成 handlers，但旧配置仍能加载，只是不生效）
• 运行 phpstan analyse --level=9 或 psalm --find-dead-code，它们比单元测试更早暴露类型签名不匹配

最常被跳过的动作是：改完 composer.json 后，没去对应包的 CHANGELOG 里逐条核对 UPGRADE 步骤。很多“升级后功能正常但日志不写”的问题，根源就是漏看了 handler 配置迁移说明——它不报错，只静默失效。