composer outdated 是唯一靠谱的“提醒”命令，它只读取 composer.json 和已安装版本进行比对，不修改任何文件；默认跳过最新包，支持 --direct、--minor-only、--patch-only、--format=json 等参数精准控制输出与用途。
用 composer outdated 查所有可更新包，不是 composer update，后者直接改锁文件，不提醒。
为什么 composer outdated 是唯一靠谱的“提醒”命令
它只读取 composer.json 和已安装版本，不修改任何文件，纯粹比对“当前装的是什么”和“按约束能升到什么”。composer update 会立刻写 composer.lock，根本不是提醒工具。
-
composer outdated默认跳过已是最新版的包，输出干净 - 加
--direct只看composer.json里你亲手写的依赖，排除传递依赖干扰 - 加
--minor-only或--patch-only能过滤语义化版本变更粒度，避免把^2.0升到3.0这类破坏性更新误判为“可更新” - 加
--format=json适合 CI 解析，退出码为3表示有更新，0表示无更新
composer outdated 常见误用与现象
运行后没输出？不是没更新，是默认只显示“有更新”的包。如果所有依赖都卡在旧约束里（比如写了 "monolog/monolog": "1.25.0"），它就沉默——这不是 bug，是设计。
- 想强制看到全部包当前 vs 最新稳定版差距？用
composer show vendor/package，看versions行（允许范围）和installed行（实际装的） - 加了
--direct却仍看到一堆 dev 包？说明你没加--no-dev，dev 依赖默认也被检查 - 输出里带
(abandoned)或(deprecated)？这不是版本问题，是包已被弃用，outdated不负责这类提示，得靠composer audit或人工查
composer audit 是查安全更新的正解，别混进版本提醒流程
composer audit 和 outdated 完全不同赛道：前者查 CVE 漏洞，后者查版本滞后。它不关心你装的是 2.8.0 还是 2.9.0，只关心这俩里有没有已知高危漏洞（比如 CVE-2023-12345）。
- 必须 PHP ≥ 8.1 且 Composer ≥ 2.5，旧版本直接报错，别硬试
- 默认检查全部依赖（含
require-dev），加--no-dev可跳过开发依赖 - 它不会告诉你“该升到哪”，只列漏洞 ID、等级和建议操作，升级动作仍要你自己跑
composer update或composer require - CI 中可用退出码判断：
0= 无漏洞，1= 有漏洞（注意不是3）
CI 自动提醒的关键不是命令，而是退出码逻辑
没人会手动去翻 outdated 输出，真正在 CI 里起作用的是它的退出码。别写 echo 就完事，得让构建流程感知状态。
- 推荐组合：
composer outdated --direct --minor-only --quiet - 退出码
0：无符合条件的更新 → 构建继续 - 退出码
3：有更新 → 可打印警告，或设为失败（set -e或 GitHub Actions 的if: ${{ failure() }}） - 别用
--dry-run替代：它模拟更新但不反映“放宽约束后能升多高”，且退出码恒为0，无法用于判断
真正容易被忽略的是约束本身——outdated 再准，也救不了写死 "foo/bar": "1.1.5" 的 composer.json。提醒只是镜子，改约束才是动手的那一步。
