composer outdated是最轻量精准的日常检查方式，仅比对已安装版本与约束下的最新兼容版，响应快、结果干净；加--direct聚焦显式依赖，!标主版本跃迁需人工审，security标漏洞须优先处理，--format=json便于ci自动化解析。
直接用 composer outdated，它能告诉你哪些包有新版本、是否含主版本跃迁、有没有安全更新——这是最准也最轻量的检查方式。
为什么不用 composer update --dry-run 做日常检查
它确实会模拟升级并输出变更，但本质是重跑依赖解析器，耗时长、易受config.platform或minimum-stability干扰，且不区分“可安全升”和“需人工审”。日常巡检没必要动这么重的逻辑。
-
outdated只比对已安装版本与当前约束下的最新兼容版，响应快、结果干净 - 加
--direct只看你在composer.json里显式写的包，避免被传递依赖带偏 - 若输出为空，先检查是否因
"prefer-stable": true把候选版本过滤掉了——临时改配置再跑一次
outdated 输出里那些标记是什么意思
关键看三列：当前装的版本、可升到的版本、右侧标记。标记才是重点：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
!表示主版本跳变（如monolog/monolog从v2.9升到v3.0），契约大概率变了，必须查 changelog 或跑测试 -
security表示该包存在已知漏洞，优先处理 -
abandoned表示包已被作者弃用，得换替代方案 - 没标记的通常是补丁或小版本更新，风险较低，但也要看是否在
require-dev里——开发依赖升错版本可能让phpunit直接报错
CI/CD 中怎么自动化检查
别等发布前才扫一遍，把它塞进每日构建流程里：
- 用
composer outdated --minor-only每日检查，避开主版本更新干扰 - 加
--format=json输出结构化数据，方便脚本解析是否有security或!标记 - 如果项目用了
config.platform（比如声明 PHP 8.1），outdated默认按平台模拟，但真实环境可能不同——CI 中建议额外跑一次composer check-platform-reqs确认
真正容易被忽略的是：很多团队把 outdated 当成“有没有新版本”的开关，却没注意它不校验当前 composer.lock 是否和 composer.json 同步。生产环境升级前，务必先跑 composer show vendor/package-name，确认输出的版本号跟 composer.json 里写的约束能对上——否则你看到的“可升级”，可能只是 lock 文件旧了而已。
