composer outdated默认只检查直接依赖，不扫描间接依赖；需加--all才显示全部包，颜色和!标识升级风险，安全漏洞须单独运行composer audit。
composer outdated 不会自动“识别冗余依赖”，也不报安全漏洞，它只告诉你：哪些包在当前 composer.json 版本约束下，有更高稳定版可升——而且这个“可升”是静态比对结果，不是运行时验证结论。
composer outdated 默认只查直接依赖，间接依赖全被忽略
你装了 laravel/framework，它拉进来 symfony/http-foundation，但你没在 composer.json 里显式写它——那 composer outdated 默认根本不会列出这个包。这不是 bug，是设计如此。
- 加
--all才能看到全部已安装包（含间接依赖、suggest包、dev 包） - 加
--direct可聚焦你亲手写的依赖，避免被几十个子依赖淹没 - 加
--no-dev跳过开发依赖，减少干扰 - 如果输出为空，先确认
composer.lock是否陈旧：composer update --lock刷新后再试
installed 和 latest 两列到底怎么看
输出里三列：包名、installed（来自 composer.lock 的实际加载版本）、latest（当前约束下 Packagist 上可用的最高稳定版）。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
installed和latest一致 → 这个包在约束范围内已是最新，不用动 - 不一致 → 表示能升，但不等于“该升”或“能安全升”；比如
"monolog/monolog": "^2.0"锁着2.10.0，latest显示3.5.0，但3.5.0不满足^2.0，composer update根本不会动它 -
latest是受约束限制的，不是 Packagist 绝对最新版；想看绝对最新，得用composer show vendor/package
颜色和 ! 号比版本号更重要
终端里的红、黄、无色不是装饰：
- 红色行（如
symfony/console v5.4.32 → v6.0.19）→ 主版本跃迁，极可能破坏兼容性 - 黄色行（如
guzzlehttp/guzzle v7.8.1 → v7.8.2）→ 仅补丁更新，大概率安全 - 带
!的行（如doctrine/dbal 3.6.4 → 3.7.0 !）→ Composer 自动识别出 BC-breaking 更改，哪怕只是次版本也得查 CHANGELOG - 没颜色 = 当前版本已是约束范围内最新，或被固定版本锁死（如
"phpunit/phpunit": "9.5.10"）
别信 outdated 列表，升级前必须做两件事
composer outdated 只负责“报信”，不判断是否真能升通。尤其要注意：
- 运行
composer why-not php:8.2或检查composer config platform.php，确认 PHP 版本兼容性 - 对目标包执行
composer update vendor/package-name --dry-run，提前暴露冲突，比直接update更省时间 - 用
composer depends vendor/package-name查谁在依赖它，避免误删核心链路依赖 - 安全漏洞要单独查：
composer audit（Composer 2.5+ 内置），outdated不管 CVE
真正容易被忽略的是：outdated 结果严重依赖本地缓存、镜像源同步状态、minimum-stability 设置和 platform 配置。同一命令，在 CI 和本地跑出不同结果，大概率不是命令问题，而是环境元数据不一致。
