composer outdated --direct 只检查 composer.json 中 require 和 require-dev 显式声明的直接依赖，不扫描 guzzlehttp/promises 等间接依赖；加 --no-dev 可排除开发依赖，--minor-only 或 --patch-only 支持粒度筛选，而 --direct --all 无效且被忽略。
composer outdated --direct 只看你自己写的 require 行
它不会扫描 guzzlehttp/promises 或 psr/http-client 这类被拉进来的子依赖，哪怕它们已落后三个小版本。输出结果只对应你亲手写在 composer.json 的 require 和 require-dev 里的包名和版本约束。
常见错误现象：运行 composer outdated --direct 后发现列表很短，但项目跑起来报 Class not found —— 很可能某个间接依赖（比如 symfony/polyfill-php81）已过时且与当前 PHP 版本不兼容，但它根本不会出现在这个命令的输出里。
- 加
--dev才能同时看到require-dev里的包（如phpunit/phpunit），否则默认只查require - 如果想排除开发依赖干扰，专注生产环境，用
composer outdated --direct --no-dev -
--direct不影响版本比对逻辑，它只是过滤输出范围；是否“可升”仍取决于composer.json中的版本约束和当前 stability 设置
为什么 --direct 比默认行为更实用
默认不加参数时，composer outdated 会列出所有已安装包（含上百个间接依赖），其中绝大多数你既没声明、也不该直接升级——比如 psr/container 升级需由 symfony/dependency-injection 驱动，手动升反而引发冲突。
使用场景集中在维护节奏控制：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 定期巡检：每月跑一次
composer outdated --direct，快速定位核心组件（如laravel/framework、doctrine/orm）是否长期未更新 - 上线前确认：检查关键业务依赖是否卡在旧版，避免因
monolog/monolog落后多个 patch 版本而错过日志格式修复 - 交接文档依据：把
--direct输出存为 baseline，新成员能一眼看清项目“主动管理”的依赖边界
--direct 和 --all 的组合陷阱
别用 composer outdated --direct --all —— 这个组合无效。--all 会取消 --direct 的过滤效果，最终还是显示全部依赖，且 --direct 被忽略（Composer 2.9.6 及以上版本会静默丢弃该参数）。
真正需要“只看直接依赖 + 更细粒度筛选”时，应选：
-
--minor-only：只提示次要版本升级（如2.4.0 → 2.5.0），避开主版本破坏性变更 -
--patch-only：聚焦安全补丁和 bug 修复（如2.4.0 → 2.4.3），适合线上紧急巡检 -
--format=json：配合jq '.packages[] | select(.name=="laravel/framework")'精准提取单个包状态
容易被忽略的稳定性影响
--direct 不改变 Composer 对稳定性的判断逻辑。如果你的 composer.json 里写着 "minimum-stability": "stable"，而某个直接依赖发布了 3.0.0-beta1，它依然不会出现在 composer outdated --direct 结果中——哪怕你本地开发时临时设过 minimum-stability: dev，也得先 composer config minimum-stability stable 再执行，否则结果不可复现。
真正决定“哪些包能被看见”的，是 composer.json 当前生效的约束 + minimum-stability + prefer-stable 三者共同作用的结果，不是命令参数本身。
