red 表示主版本升级（如 v2.x→v3.x），可能存在不兼容变更；yellow 表示次版本或修订版升级（如 v1.2→v1.3），通常向后兼容但小众库可能违反此惯例。
composer outdated 显示的包为什么有的标 red，有的标 yellow
颜色代表更新风险等级：red 是主版本升级（如 v2.x → v3.x），可能含不兼容变更；yellow 是次版本或修订版本升级（如 v1.2 → v1.3 或 v1.2.1 → v1.2.5），通常向后兼容。但别光看颜色——有些包把破坏性改动塞进次版本里，尤其小众库。
实操建议：
- 运行
composer outdated --direct只看你require里直接声明的包，避免被间接依赖干扰判断 - 加
--minor-only参数可过滤掉主版本更新，快速聚焦安全/小修类更新 - 用
composer outdated --format=json输出结构化数据，方便脚本解析或对接 CI 检查
为什么 composer outdated 不显示某些明显该更新的包
常见原因是这些包被锁在 composer.lock 里，且当前 require 版本约束太宽（比如写的是 "monolog/monolog": "^2.0"），而 lock 文件里存的是 2.4.0，最新是 2.10.0 ——它其实“没过期”，只是没拉到最新小版本。
实操建议：
- 加
--all参数强制检查所有已安装包（包括require-dev和间接依赖） - 确认是否启用了
minimum-stability限制，比如设成stable就会跳过RC或beta版本，即使它们在 packagist 上已标记为 latest - 运行
composer show monolog/monolog对比输出里的versions和latest字段，能看清到底卡在哪一环
composer outdated 和 composer update 的执行逻辑差异
composer outdated 只读取 composer.json + composer.lock + packagist 元数据，不改任何文件、不下载包、不解析依赖图；composer update 则会重新解出整张依赖图，可能触发大量重装甚至版本回退。
这意味着：outdated 看起来“可更新”的包，update 时未必能升上去——比如 A 包想升到 v3，但 B 包只兼容 A v2，Composer 就会放弃升级 A，甚至把 B 也降级来保图稳定。
实操建议：
- 别直接
composer update vendor/package，先用composer outdated vendor/package确认目标版本，再加--with-dependencies测试连带影响 - 升级前删掉
composer.lock再跑outdated？不行。这会让结果失去参照基准，outdated将默认按require约束找最新满足项，而非对比当前已装状态 - CI 中建议用
composer outdated --direct --no-dev --strict，退出码非 0 即视为有需人工确认的更新，避免自动升级踩坑
如何让 outdated 结果更贴近真实升级风险
默认输出只告诉你“能升到哪”，不告诉你“升了会不会炸”。真正关键的是测试兼容性，而不是版本号本身。
实操建议：
- 对 PHP 版本敏感的项目，加
--ignore-platform-req=php再跑一次outdated，看是否因 PHP 版本锁死了某些包的更新路径 - 结合
composer why-not vendor/package:v3.0.0查具体哪个依赖在拦路，比纯看 outdated 更准 - 用
composer prohibits vendor/package 3.0.0找出所有阻止该版本安装的约束条件，包括conflict声明和平台配置
实际更新前，最常被忽略的是 autoload 变更和 post-install-cmd 脚本兼容性——有些包 v3 删除了旧类名或改了事件钩子，outdated 完全不提示这些。