Composer status命令不直接显示“被修改过的依赖”，而是检查vendor/目录中已安装包是否与composer.lock一致，仅对Git源码包校验文件变更，加-v参数后才对dist包比对哈希并显示具体差异。
Composer 的 status 命令本身**不直接显示“被修改过的依赖”**，它只检查 vendor/ 目录下已安装的包是否与 composer.lock 记录的状态一致。所谓“被修改”，通常指源码被手动改动（如改了 vendor 里的某行代码），而 status 正是用来发现这类本地篡改的。
status 命令的核心作用
它逐个比对 vendor/ 中每个包的当前文件状态（如 Git HEAD、文件哈希或时间戳）和 composer.lock 中记录的原始安装快照。一旦发现不一致，就标为“modified”。
- 仅适用于使用 Git 克隆安装的包（即
source方式安装，且vendor/<vendor>/<package>是一个 Git 工作目录） - 对通过
dist方式（zip/tar 下载）安装的包，默认不校验文件内容，除非加-v - 不会检测你是否删了某个包、改了
composer.json却没 run install —— 那是validate或outdated的事
-v 参数到底做了什么？
加 -v（verbose）后，status 不再只报“modified”，而是给出具体差异线索：
- 对 Git 包：显示
git status --porcelain的输出（如M src/Helper.php表示该文件被修改） - 对 dist 包：尝试计算实际文件的 SHA256 哈希，并与
composer.lock中dist.shasum字段比对（需 PHP 支持 hash 扩展） - 同时列出所有被跳过校验的包（比如没 Git 目录、无 shasum 记录等），帮你确认哪些“看似干净”其实没被验证
怎么用才真正查出问题？
推荐组合命令，避免漏判：
- 基础扫描：
composer status—— 快速看有没有标 “modified” 的包 - 深度排查：
composer status -v—— 查哪几个文件动了，或 dist 包哈希是否对得上 - 强制重验所有（含 dist）：
composer status -v --ignore-platform-reqs（非必需，但可绕过某些环境限制） - 配合 git 检查：
git status --ignored看 vendor 是否被 git 忽略 —— 如果 vendor 在 git 管理中，status 结果可能失真
常见误判和注意事项
status 报 “modified” 不一定代表你“有意改代码”，也可能是：
- IDE 自动生成了
.phpstorm.meta.php或.idea/这类文件（Git 默认忽略，但 status 会扫到） - 运行了
phpunit或其他工具，在 vendor 里生成了临时缓存（如vendor/bin/.phpunit） -
composer.lock是旧版本生成的，而新 Composer 安装时用了不同哈希算法（极少见，但 v2.2+ 有变更） - 包本身在
post-install-cmd里写了修改自身文件的脚本（不良实践，但存在）
遇到误报，可用 git -C vendor/<vendor>/<package> checkout . 或手动删临时文件清理；若确需保留修改，请 fork 包并 require 你的分支，别直接改 vendor。
