composer outdated 仅比对版本号并输出静态快照，不提供更新日志、发布时间、bug修复或bc破坏信息，也不联网查github releases或解析changelog.md。
composer outdated 只能看“有没有新版本”，看不到日志
这是最常被误解的一点：composer outdated 甚至 composer show --outdated 都不提供任何更新日志内容——它只比对版本号，输出类似 monolog/monolog 3.4.0 → 3.5.0 这样的静态快照。发布时间、修复了哪些 bug、是否破坏 BC，全都不在输出里。
- 它不联网查 GitHub Releases，也不解析项目根目录下的
CHANGELOG.md - 它读的是本地
composer.lock和 Packagist 的元数据缓存，连 tag 时间戳都没有 - 如果你依赖
"monolog/monolog": "^3.4"，而 v3.5.0 刚发布 2 小时，outdated能立刻显示，但你依然不知道这版修了啥
查 changelog 的实际路径只有两条：GitHub + 人工定位
Composer 不负责分发变更说明，维护者写在哪，你就得去哪找。主流开源包基本都把更新日志放在两个地方：
-
GitHub Releases 页面：访问
composer show monolog/monolog输出的source地址（比如https://github.com/Seldaek/monolog），再点Releases标签页，按 tag 翻 v3.5.0 的发布说明 -
仓库根目录的 CHANGELOG.md：有些项目（如 Laravel）习惯把完整日志放这里，可直接用
curl -s https://raw.githubusercontent.com/laravel/framework/11.x/CHANGELOG.md | head -20快速扫一眼最新段落
注意：composer show 输出的 versions 列表只是当前源里“能装的版本”，不是“已发布的全部版本”；某些包会删旧 tag 或用私有分支，这时候 GitHub 页面可能比 Packagist 更准。
想自动化？得自己补工具链，别指望 composer 原生支持
截至 2026 年 2 月，Composer 仍无内置命令调用 GitHub API、渲染 Markdown 或 diff 版本间变更。真要批量查日志，常见做法是组合脚本：
- 用
composer show --format=json vendor/package提取source.url和当前version - 调用
gh api repos/{owner}/{repo}/releases/tags/v{new_version}（需安装 GitHub CLI） - 或用
git log v3.4.0..v3.5.0 --oneline -- changelog.md（前提是克隆了源码）
这类方案要处理权限、网络超时、tag 命名不规范（比如用 3.5.0 而非 v3.5.0）等问题，小项目手动点两下反而更快。
安全更新和重大变更根本不会自动标出来
composer outdated --security-only 能标出有已知漏洞的包，但它只告诉你“该升”，不告诉你“为什么该升”——CVE 编号、影响范围、是否需要代码调整，全得你点进对应 issue 或安全公告里看。
- 比如
symfony/http-foundation某次 patch 升级可能修复 SSRF，但outdated输出里就一行5.4.33 → 5.4.34 [security] - 主版本升级（如
laravel/framework 10.x → 11.x）更危险：--major-only参数只过滤输出，不阻止你误执行composer update - 最易忽略的是 fork 包：你用的是公司内网 GitLab 上的
myorg/monolog，outdated仍拿 Packagist 的原版比，结果“没更新”其实是假象
真正关键的更新细节，永远藏在维护者写的文字里，而不是 Composer 的命令行输出中。
