composer status -v 能检测 vendor 目录中依赖包的本地修改状态，尤其对 source 模式安装的包可显示未提交更改、新增文件等 Git 状态，帮助开发者发现潜在问题。该命令通过区分 dist 与 source 安装方式，揭示依赖是否被改动，确保环境一致性，避免因临时修改引发协作冲突，提升项目可维护性。
composer status -v
这个命令，直白点说，就是让你能深入了解你的项目依赖包的“健康状况”。它会详细展示你的
vendor
目录中，那些通过 Composer 管理的包是否被本地修改过，或者它们是以何种方式（比如从哪个 Git 仓库）安装的。特别是那个
-v
参数，没有它，这个命令通常是沉默的，有了它，你才能看到那些关键的、可能被你忽略的细节。
解决方案
在我日常开发中，
composer status -v
简直是排查依赖问题的一个小雷达。它主要检查几件事：首先，它会扫描你的
vendor
目录，看看里面的依赖包是不是“原装”的。如果你安装某个包时选择了
source
模式（这意味着 Composer 直接克隆了它的 Git 仓库），那么
composer status -v
就会像一个 Git 仓库的守卫者，告诉你这个包的仓库里有没有本地修改，有没有未提交的文件，甚至有没有未跟踪的新文件。这对于我们这些经常需要调试依赖包、临时打补丁，或者只是想深入了解某个库实现的人来说，简直是不可或缺的。
这命令还能清楚地显示一个包是
dist
方式安装的（通常是一个预打包的压缩文件，只读），还是
source
方式安装的（一个可修改的 Git 仓库）。这种区分非常重要，因为它直接影响你是否应该、以及如何去修改这些包。我个人觉得，
composer status -v
其实就是 Composer 提供给我们的一面镜子，它映照出我们对依赖包所做的一切“小动作”，无论是无意的还是有意的，都能被它捕捉到。
composer status -v
composer status -v
如何帮助开发者识别本地依赖问题？
我经常遇到这样的场景：某个功能在我本地跑得好好的，但同事拉取代码后，或者部署到测试环境后就“水土不服”了。排查下来，往往发现是我在某个依赖包里临时改了一行代码，比如为了调试某个 bug，或者为了测试一个临时的解决方案，结果忘了还原，或者忘了在
composer.json
里正确地声明这个变更。这时候，
composer status -v
就能迅速而精准地揪出这些“隐形炸弹”。
它会明确告诉你，哪个包的 Git 仓库有未提交的修改，哪个文件被动过了，甚至哪个文件是新增但未被 Git 追踪的。这不仅仅是代码层面的问题，很多时候也是团队协作的痛点。你改了依赖包，没告诉团队其他成员，他们拉下来代码，可能就会面临一堆莫名其妙的问题，然后就是漫长的排查和“我本地没问题啊”的尴尬对话。所以，在我看来，这个命令是确保开发环境一致性、减少这种扯皮现象的利器。它实际上是把
git status
在
vendor
目录下所有
source
模式安装的包里都跑了一遍，然后汇总给你看，但更聚焦于 Composer 管理的包。这种能力，对于维护一个健康、可预测的开发环境来说，价值不言而喻。
理解 Composer 的
dist
dist
与
source
安装模式对
composer status -v
的影响
Composer 安装依赖包主要有两种模式：
dist
和
source
。理解它们之间的区别，是正确使用
composer status -v
的前提。
dist
模式是 Composer 的默认行为。在这种模式下，Composer 会下载一个预打包的压缩文件（比如
.zip
或
.tar.gz
），然后解压到你的
vendor
目录。这种方式安装的包，通常是只读的，你也不应该去修改它，因为下次
composer update
或者
composer install
可能会直接覆盖掉你做的任何本地更改。对于
dist
模式安装的包，
composer status -v
通常不会有太多输出，因为它不期望这些包有本地修改，而且它们也不是 Git 仓库，自然也就没有 Git 状态可言。
而
source
模式，则是直接克隆包的 VCS 仓库（比如 Git 仓库）到
vendor
目录。当你需要对依赖包进行调试、提交补丁到上游项目，或者只是想深入了解它的内部实现时，
source
模式就显得尤为重要。
composer status -v
的真正威力，主要体现在对
source
模式安装的包的监控上。它会进入这些 Git 仓库，执行类似于
git status
的检查，然后告诉你哪些文件被修改了，哪些是新文件，哪些是未跟踪的。这种细致的反馈，让你能清楚地知道自己对依赖包做了什么改动，以及这些改动是否需要被处理（比如提交、回滚或记录）。所以，只有当你以
source
模式安装了依赖包时，
composer status -v
才能发挥其最大的作用，帮你管理这些可修改的依赖。
除了本地修改，
composer status -v
composer status -v
还能揭示哪些不为人知的依赖状态？
除了显而易见的本地修改，
composer status -v
偶尔还会透露一些你可能没注意到的、更深层次的依赖状态信息。这命令就像一个有点啰嗦但很细心的管家，它不仅仅关心你有没有把东西放错地方，还可能提醒你一些潜在的问题。
比如，如果你在
composer.json
中使用了
path
类型的仓库，把本地的一个目录当作依赖包来引入，
composer status -v
在某些情况下可能会显示这个“包”的状态，尽管它可能不是一个标准的 Git 仓库，或者至少会确认它的存在。虽然它不会直接告诉你一个包是不是符号链接（symlink），但如果这个符号链接指向的源头是一个
source
模式安装的包，并且那个源头有修改，
composer status -v
依然能捕获到这些变化。这其实提供了一个间接的检查点。
更深层次地讲，这个命令在某种程度上反映了 Composer 对
vendor
目录的“控制欲”——它希望这个目录是干净的，是与
composer.lock
文件严格对应的。任何偏离这种“纯洁”状态的情况，都可能被
-v
参数下的
status
命令揪出来。这有时也包括一些权限问题，如果 Composer 无法正确读取某些文件或目录，也可能在输出中有所体现，尽管这不常见，但它确实是工具反馈系统的一部分。这就像你家里的一个智能警报器，虽然它主要功能是防盗，但偶尔也能提醒你门没关好，或者某个窗户有点松动。它提供的不仅仅是“是”或“否”的答案，而是一个更全面的“健康报告”。