Composer怎么查看包的更新日志_Composer版本迭代追踪方案

但问题也随之而来：它只告诉你“有更新”，却不告诉你“更新了什么”。

• 这个命令不会联网去查询 GitHub Releases，更不会主动解析项目的 CHANGELOG.md 文件。
• 因此，你无从知晓新版本是否修复了类似 log() throws on null context 这样的关键 Bug。
• 同样，那些可能导致代码崩溃的破坏性更新（BC break），比如 LoggerInterface::log() 方法签名的变更，它也不会特意标出。

不过，这个命令依然有它的实用技巧：

• 加上 --direct 参数可以过滤掉间接依赖，只聚焦于你在 composer.json 中直接声明的包。
• 使用 --format=json 参数可以将输出转为 JSON 格式，方便后续用脚本提取目标版本号，再传递给其他工具（如 curl 或 gh api）进行深度查询。
• 需要警惕的是，--security-only 参数只能标记“存在安全漏洞”，但无法告诉你“漏洞是如何修复的”。依赖它来代替阅读完整的更新日志，风险不小。

真要看到更新内容，得进 vendor 目录或调 GitHub API

如果你决心要看到最原始的变更内容，那么有两条主要路径。

路径一：深入 vendor 目录。 前提是你的包是以源代码（source）方式安装的（即在 composer.json 中配置了 "prefer-source": true，或安装时使用了 --prefer-source 参数）。

• 进入包目录：cd vendor/monolog/monolog
• 查看两个版本间变更日志文件的改动：git log --oneline v3.4.0..v3.5.0 -- CHANGELOG.md
• 或者直接看代码差异统计：git diff --stat v3.4.0..v3.5.0 src/

路径二：调用 GitHub API。 如果没有安装源代码，又不想手动打开浏览器，可以尝试自动化：

• 先用 composer show -s vendor/package 拿到仓库地址。
• 然后使用 GitHub CLI 工具查询：gh api repos/{owner}/{repo}/releases/tags/v3.5.0
• 这里有个小坑需要注意：标签（tag）名称可能不含 v 前缀（例如是 3.5.0 而不是 v3.5.0），所以有时需要尝试两次。

这条路线上也有几个容易踩的坑：

• 对于私有包或托管在 GitLab 等平台的项目，GitHub CLI 会失效，需要改用 curl 命令并加上个人访问令牌（token）。
• CHANGELOG.md 文件可能不在 main 分支，而在 stable
• 有些包会把更新日志放在 UPGRADE.md 里，或者直接放在官方文档站（例如 lara vel.com/docs/11.x/changelog）。在这种情况下，composer show 输出的 homepage 字段往往比 source 字段更准确。

别指望 composer update --dry-run 带日志

最后，千万别被 composer update --dry-run -vvv 那看似详尽的输出给骗了。这个“模拟运行”模式会跳过很多关键检查，比如锁文件校验、平台扩展检查，甚至部分缓存验证。一个典型的例子是：真实执行时可能会因为缺少 ext-redis 扩展而失败，但 dry-run 却可能悄无声息地通过。

更关键的是，它根本不触发任何远程请求，连 Git clone 操作都不会模拟。所以，指望它附带提供更新日志，是完全不现实的。

那么，升级前真正有效的做法是什么呢？

• 首先，用 composer show vendor/package --latest 确认最新版本号和发布日期。
• 然后，立刻手动打开该包在 GitHub（或其他托管平台）的 Releases 页面，仔细阅读 “What’s Changed” 区域。
• 如果这次升级涉及主版本号变更（比如从 ^2.0 升级到 ^3.0），务必额外花时间扫一眼 UPGRADING.md 文件或官方的迁移指南，这里面通常包含了破坏性变更的详细说明。

还有一个最容易被忽略的点：很多知名包的更新日志并不放在 GitHub 的 Releases 里，而是维护在其独立的官网文档页面上。这时，composer show 命令输出的 homepage 字段，其可靠性远超任何自动化脚本。手动访问，仔细阅读，依然是目前最靠谱的方法。