直接运行 composer outdated 是最轻量的检查方式，但它默认仅扫描 composer.json 中 require 和 require-dev 显式声明的包，漏掉间接依赖（如 psr/log）、dev 工具（如 phpunit/phpunit）及被 replace 隐蔽覆盖的包；需加 --all 才全面识别，其中带 ! 表示 bc-breaking、红色箭头提示主版本跃迁、黄色行代表补丁更新。

直接运行 composer outdated 是最可靠、最轻量的检查方式——它不改文件、不联网查 changelog，只比对本地 composer.lock 和 Packagist 上当前满足约束的最新兼容版本。

为什么默认 composer outdated 会漏掉大部分包

它默认只扫描你 composer.json 中 require 和 require-dev 下显式声明的包。以下三类关键包它完全不扫：

• psr/log、symfony/polyfill-php81 这类被其他包带进来的间接依赖（比如通过 laravel/framework 引入）
• phpunit/phpunit 这类仅在 require-dev 里但没被显式列在 outdated 默认范围的工具
• 被 "replace": {"monolog/monolog": "*"} 这类规则隐式覆盖的包，Composer 认为“已由主包接管”，跳过独立检查

所以，真想摸清全貌，必须加 --all： composer outdated --all

Discussion Composer

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

下载

composer outdated --all 输出里那些符号和颜色什么意思

终端输出不是装饰，每个标记都对应实际风险：

• 带 ! 的行（如 guzzlehttp/guzzle 7.4.5 → 7.5.0 !）：Composer 自动识别出该更新含 BC-breaking 更改，哪怕只是次版本升级，也得去翻 CHANGELOG
• 红色箭头（如 v5.4.32 → v6.0.19）：约束允许主版本跃迁，但很可能破坏兼容性；JSON 输出中对应字段是 "latest-status": "major"
• 黄色行（如 v5.4.32 → v5.4.37）：补丁级更新，大概率安全，但仍有行为变更可能（比如日志字段名从 context 改成 extra）
• 不带 * 却有新版本：说明你用了 dev-main 或 dev-develop 分支，Composer 不把它当稳定版比对，不是“没问题”，而是“没法比”

怎么安全地把检查结果转成可执行动作

outdated 只是看，不升级。真正动手前，先用 --dry-run 预览 Composer 实际打算怎么动：

• 查单个包影响：composer update guzzlehttp/guzzle --dry-run -v，看是否连带降级或冲突
• 避免意外主版本升级：composer outdated --minor-only 先过滤，再对结果里的包逐个 composer update vendor/package-name
• CI/CD 中别靠人眼扫：composer outdated --all --format=json | jq -r '.packages[] | select(.latest_status == "major")'，自动拦截高风险项
• 升级后类找不到？90% 是 autoload 没刷新：composer dump-autoload -o 必跑

真正容易被忽略的是：如果 composer.lock 本身没提交，或者本地缓存过期，outdated 读的就是旧元数据——它显示“无更新”，不代表真实环境安全。