composer status 仅校验本地 vendor/ 文件与 composer.lock 的哈希一致性，用于检测是否被手动修改；它不显示变更日志、不查远程更新、不依赖网络，输出如“monolog/monolog has uncommitted changes”。
composer status 命令不显示变更日志，它只检查本地 vendor/ 文件是否与 composer.lock 一致——换句话说，它回答的是“有没有被手动改过”，而不是“这个包更新了什么”。
composer status 是干啥的？
composer status 的唯一职责是比对已安装包的文件哈希（来自 composer.lock）和当前 vendor/ 目录下实际文件的哈希。一旦发现不一致，就列出那些“被改动过”的包路径，并提示你可能执行了 git checkout、rm -rf 或手改源码等操作。
- 它不查远程新版本，不读
CHANGELOG.md，也不调 GitHub API - 它不依赖网络，纯本地校验，所以快但信息极有限
- 输出类似：
monolog/monolog has uncommitted changes in vendor/monolog/monolog
想看包的变更日志，该用什么？
Composer 本身没有内置命令能拉取或解析变更日志——这是设计使然，不是功能缺失。所有靠谱做法都绕不开外部来源：
- 先用
composer show monolog/monolog查source类型和仓库地址（比如https://github.com/Seldaek/monolog） - 若
source是git（即装包时用了--prefer-source），可直接进目录查：git -C vendor/monolog/monolog log --oneline v2.8.0..v2.9.0 - 更通用：访问 GitHub Releases 页面，或找项目根目录下的
CHANGELOG.md（多数主流包都维护） - 想自动化？得自己写脚本调 GitHub Compare API：
/repos/{owner}/{repo}/compare/v2.8.0...v2.9.0，但需处理认证、限流、404
为什么不能信 composer outdated 的“最新版”？
composer outdated 显示的“最新稳定版”只是 Packagist 缓存里的元数据快照，不含发布时间、破坏性变更标记、安全通告等关键上下文：
- 它默认忽略
dev-、beta、rc版本，但有些项目把重要修复发在dev-main上 - 它不告诉你
v3.0.0是否含 BC break，也不标哪个 commit 修了 CVE-2025-1234 - 加
--direct只过滤 root require，但嵌套依赖的变更照样可能崩掉你的代码 - 运行
composer outdated --format=json | jq '.[] | select(.latest != .version)后，仍得人工点开每个包的 Releases 页面核对
日志文件位置别搞混：composer.log 不是变更日志
很多人搜“composer 日志”就直奔 ~/.composer/logs/composer.log，但这个文件只记录 Composer 自身的命令执行过程（比如下载失败、权限错误、插件加载异常），和“某个包发布了什么新功能”完全无关。
- 它不会出现
monolog added PsrLogAwareTrait in v2.9.0这类内容 - Debian/CentOS 下路径虽统一为
~/.composer/logs/composer.log，但默认可能根本不存在——只有出错且启用了日志配置才会生成 - 真要留痕，最可靠的是重定向：
composer update -vvv > update-debug.log 2>&1
真正需要知道的只有一条：变更日志不在 Composer 里，而在包作者写的文档、提交记录、发布页里。工具只是帮你定位到那里，没法替你读。
