composer outdated 默认只检查直接依赖，不扫描间接依赖，因此如 monolog/monolog 等子依赖即使过期也不会显示；若无输出，通常因所有直接依赖均满足版本约束且无可用更新，需加 --all 查全部依赖，或结合 composer audit 检测安全漏洞。
composer outdated 为什么显示不了过期包？
默认情况下 composer outdated 只显示「主依赖」（即 require 和 require-dev 中直接声明的包），不会递归检查子依赖是否过期。如果你发现命令没输出，很可能是因为所有直接依赖都已是最新稳定版，但深层依赖（比如 monolog/monolog 被 laravel/framework 拉入）可能早已落后几个小版本。
实操建议：
- 加
--all参数查看全部过期包：composer outdated --all - 加
--direct（或不加参数）只看顶层依赖，适合快速确认自己是否该升级 Laravel、Symfony 等主框架 - 加
--minor-only或--patch-only过滤语义化版本变更粒度，避免被v3.12.0 → v4.0.0这类破坏性更新吓到 - 注意：如果项目锁定了 PHP 版本（如
"php": "^8.1"），某些新包会因平台约束被跳过，此时需结合composer show -p查看平台配置
如何判断一个过期包能不能安全升级？
不是所有标红的过期包都值得立刻升级——关键看它是否在你代码中被直接调用、是否有已知安全漏洞、以及上游是否已停止维护。例如 symfony/polyfill-php81 过期了，但只要你的 PHP 版本仍是 8.1，它就只是“功能冗余”，而非风险点。
实操建议：
- 先查 CVE：访问 symfony security 或 GitHub Security Advisories，搜索包名 + “advisory”
- 看
composer show vendor/package输出的type字段：如果是library或symfony-bundle，大概率需要关注；若是metapackage（如laravel/laravel）或dev-dependency，影响范围通常有限 - 运行
composer depends vendor/package查谁在用它，若只有测试工具（如phpunit/phpunit）依赖，可暂缓 - 对
dev分支或@dev版本号要格外小心：composer outdated不会提示这类不稳定版本是否“过期”，但它可能早已被弃用
composer update 的实际执行逻辑和陷阱
composer update 默认只更新 composer.lock 中记录的版本，并不强制升到最新可用版——它尊重 composer.json 中的版本约束（如 "guzzlehttp/guzzle": "^7.2"）。这也是为什么有时 outdated 显示有新版，update 却没反应。
实操建议：
- 想升到满足约束的最新版：用
composer update vendor/package（指定包）或composer update（全量） - 想忽略
composer.lock强制重算依赖图：加--with-all-dependencies，但务必先git commit，否则容易引入隐式冲突 - 生产环境禁止直接
composer update：应始终基于composer.lock部署，CI 流程中用composer install --no-dev --optimize-autoloader - 注意
minimum-stability设置：若设为stable，即使outdated显示v2.5.0-rc1更高，也不会被纳入更新候选
长期项目怎么避免依赖失控？
没有银弹，但有两个硬动作能显著降低维护成本：一是把 composer outdated --direct --minor-only 加进 CI 的每日定时任务，邮件通知负责人；二是对核心包（如 doctrine/orm, spatie/laravel-permission）单独建 .github/dependabot.yml 规则，让它只提 minor 补丁 PR，不碰 major 升级。
真正容易被忽略的是「间接依赖的生命周期」：比如你用的 aws/aws-sdk-php v3.200 依赖 guzzlehttp/psr7 ^1.9，而后者早在 2023 年就 EOL 了，但只要你没直接 require 它，outdated 就不会提醒。这种链路只能靠 composer depends guzzlehttp/psr7 主动挖，或者用 composer show --tree 手动翻三层依赖树。
