composer outdated 默认只检查 require 区块的直接依赖且仅显示版本约束内可升级的包，如 "monolog/monolog": "^2.8" 不会提示 3.5.0；需加 --all 查间接依赖，用 --format=json 配合 jq 解析，安全漏洞须单独执行 composer audit。
composer outdated 默认只显示你亲手写进 composer.json 的包里“有更新可用”的那部分，不扫子依赖、不报安全漏洞、不告诉你哪些该优先升——想靠它一眼看清项目依赖健康度，必须加参数、看颜色、盯符号。
为什么 composer outdated 没输出，但实际有包该升级？
最常见原因是它默认只检查 require 区块里的直接依赖，且仅列出「当前版本约束下允许升级」的包。比如你写了 "monolog/monolog": "^2.8"，而最新版是 3.5.0，它不会显示——因为主版本跃迁超出了 ^2.8 的范围。
- 执行前先确保
composer.lock是最新的：composer update --lock - 私有仓库没配
repositories？对应包根本不会出现在结果里 - 本地缓存过期也会导致比对失准：
composer clear-cache - 如果用了
config.platform模拟 PHP 版本，某些包可能因兼容性判断被过滤掉
怎么查全部依赖（含 monolog/monolog 这类间接包）？
加 --all 是唯一办法，但它会把整个依赖树摊开，包括几十个稳定无更新的包，噪音极大。
-
composer outdated --all：列出所有已安装包的最新稳定版（不管是否在你的版本约束内） - 搭配
--minor-only或--patch-only缩小范围，避免被主版本变更淹没 - 用
grep -v 'dev-'或jq 'select(.packages[].name | contains("dev-") | not)'过滤掉dev-main类开发分支结果 -
--no-dev可跳过require-dev中的包，减少干扰
颜色和 ! 符号到底在警告什么？
终端里红、黄、绿不是装饰，是升级风险等级信号，! 更是高危提示。
- 红色箭头（如
symfony/console 6.4.3 → 7.0.0）：满足你当前版本约束的新版，但含非补丁级变更（minor/major），可能带新功能或不兼容改动 - 黄色箭头（如
psr/log 2.0.0 → 3.0.0）：新版跨主版本，大概率 BC-breaking，不能直接升 - 带
!的行（如doctrine/dbal 3.6.4 → 3.7.0 !）：Composer 已从conflict字段识别出重大变更，必须查 CHANGELOG，不能跳过 - 没颜色 = 当前已是最新稳定版，或你在
composer.json里锁死了具体版本（如"foo/bar": "1.2.3"）
如何自动化判断哪些包该升级？
文本输出没法进 CI，必须用 --format=json，但注意它的结构不是扁平数组，而是嵌套对象。
-
composer outdated --direct --format=json：只查显式声明的包，适合日常维护 -
composer outdated --all --format=json | jq -r '.packages[] | select(.latest-status == "major") | "\(.name) \(.installed.version) → \(.latest.version)"'：筛出主版本跃迁项 - CI 环境中禁用颜色：
--no-ansi --format=json，避免 ANSI 控制符污染解析 - 安全漏洞不能靠
outdated发现，必须单独跑：composer audit（Composer 2.5+ 内置）
真正容易被忽略的是：看到 not in require 别跳过——这表示它是间接依赖，没人显式管它；升级前先用 composer depends vendor/package 查谁在用它，否则可能一升就崩。
