Composer不提供查看更新日志的内置命令，composer show -l仅显示已安装版本与最新版本号，不包含变更内容；需通过composer show vendor/package -s获取源码地址后手动查阅GitHub Releases或CHANGELOG.md。
composer show -l 显示已安装包的更新日志
Composer 本身不内置「版本更新记录」功能，composer show 命令是唯一能直接查到包变更线索的原生命令。加 -l（lowercase L）参数可列出所有已安装包及其最新可用版本，但它不显示历史更新时间或 diff —— 只告诉你「当前装的是 v2.3.1，远程有 v2.4.0」。
实际使用中容易误以为 composer show --outdated 能看到更新原因，其实它只输出版本号差异，没有提交信息、PR 链接或 changelog 提示。
-
composer show -l：适合快速扫一遍哪些包有新版 -
composer show vendor/package：查单个包的详细信息，含source字段（通常是 Git 仓库地址），可手动去 GitHub/GitLab 翻 tag 或 Releases 页面 - 若包没维护 Releases，
git log v2.3.1..v2.4.0（需先 clone 源码）才是真实更新记录来源
用 composer audit 审计安全变动（Composer 2.5+）
composer audit 是 Composer 2.5 引入的正式审计命令，它不是查「功能更新」，而是查「安全修复」—— 底层对接 composer/advisories 数据库，返回 CVE 编号、影响版本范围、是否已修复等关键字段。
常见错误是运行后没输出就以为「没问题」，其实默认只检查当前 vendor/ 中已安装的包；如果某包在 composer.json 里但没 install，它不会报。另外，它不校验 lock 文件变动，只看实际安装结果。
-
composer audit --format=json：方便脚本解析，字段含advisory、affectedVersions、fixedIn -
composer audit --no-dev：跳过 dev-dependencies，避免 CI 报一堆低风险警告 - 注意：它不替代
composer update，只是告诉你「该不该更新」
从 composer.lock 解析项目实际变动（diff + git blame）
composer.lock 是唯一记录每次依赖变更的权威文件。想还原某次更新到底改了什么，不能只看命令行回显，得对比 lock 文件的 Git 历史。
典型场景：上线后出问题，要确认是不是某次 composer update foo/bar 带来的副作用。这时 git diff HEAD~1:composer.lock HEAD:composer.lock 比翻命令记录靠谱得多 —— 它会清晰标出 packages 和 packages-dev 下增删改的包名、版本、commit hash、dist reference。
- 重点关注
content-hash字段变化：只要它变了，说明依赖图确实有实质更新 - 如果 lock 文件没进 Git（常见于遗留项目），审计就失去依据，只能靠
composer show倒推，准确率大幅下降 - 用
git blame composer.lock可定位哪次 commit 引入了某个特定包，尤其适合排查「谁偷偷加了 dev-master」
第三方工具补足 changelog 缺失（如 composer-changelog）
社区有几个小而准的 CLI 工具能自动拉取 packagist.org 或 GitHub 的 changelog，比如 composer-changelog。它不修改 Composer 行为，只是封装了「查包主页 → 找 releases API → 渲染本地终端」的流程。
但它依赖包作者规范写 release note。很多 PHP 包只打 tag 不写 description，这时候工具返回空或乱码是常态，别怪工具不好用，是上游没填。
- 安装：
composer global require webmozart/composer-changelog - 用法：
composer changelog vendor/package，会尝试打开浏览器或打印最近 3 条 release 内容 - 注意：它不审计安全性，也不校验 lock，纯属信息增强；生产环境建议搭配
composer audit使用
真正难的不是查更新记录，而是判断「这个更新要不要上」—— 版本号升了 patch 还是 major？有没有破坏性变更？lock 文件里那个 commit hash 对应的 PR 里写了什么？这些没法靠一个命令解决，得把 composer.lock、Git 历史、包源码仓库三者串起来看。
