composer outdated 是查看可更新包最准确的方式，但默认只显示当前锁文件版本与仓库最新稳定版存在差异的包，不包括已锁定或兼容范围内的版本；需加 --all、--direct 等参数才能全面掌握升级空间。
直接看结论： composer outdated 是查看可更新包最准确的方式，但默认只显示有新版本的包（不包括已锁定版本），且不区分安全更新和功能更新——想全面掌握升级空间，必须加参数。
为什么 composer outdated 默认不显示所有包？
它只列出「当前 composer.lock 中安装的版本」与「仓库中最新稳定版」存在差异的包。如果某个包在 composer.json 中用固定版本（如 "monolog/monolog": "2.9.1"）或带 ^ 但最新版仍在兼容范围内（如锁里是 2.9.1，最新是 2.9.2），它默认不显示——因为 Composer 认为“无需更新”。
实操建议：
- 加
--all参数强制列出所有已安装包，并标注是否为最新版：composer outdated --all - 加
--direct只看composer.json显式声明的包（排除依赖树里的间接依赖） - 加
--minor或--patch限制只显示小版本或补丁级更新，避免意外升到不兼容的大版本
composer outdated 和 composer update --dry-run 有什么区别？
前者是「静态比对」：读取 composer.lock 和 Packagist 元数据，不解析约束逻辑；后者是「模拟执行」：实际运行依赖求解器，考虑 require-dev、平台配置、conflict 等全部规则。
常见错误现象：某包在 outdated 里显示可升到 v3.0.0，但 update --dry-run 却报冲突——说明该版本与其他依赖不兼容，或被 platform 配置（如 PHP 版本）挡住了。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
使用场景：
- 日常巡检用
outdated快速扫一遍 - 准备升级前务必跑一次
composer update --dry-run，尤其涉及symfony/*或laravel/framework这类核心包 - CI 中建议两者都跑：
outdated --direct --minor+update --dry-run --with-dependencies
如何快速识别安全更新（security updates）？
Composer 本身不内置 CVE 检测，但会从 Packagist 接收安全公告元数据。只要你的 composer.lock 是近期生成的，outdated 就能标出带安全修复的版本。
关键点：
- 加
--security-only只显示已知存在安全风险、且有修复版本的包（需 Composer 2.2+） - 输出中带
[security]标签的行，代表该更新包含安全补丁 - 注意：这个标签依赖社区上报，不是实时扫描——不能替代专用工具如
roave/security-advisories或phpstan-security
真正容易被忽略的是：某些包虽有新版，但你的项目用了 fork 或私有仓库源，outdated 仍按 Packagist 比对，结果可能不准。这时候得手动检查 repositories 配置，并用 composer show vendor/package 确认实际来源。
