/vendor必须被git忽略，因其是动态生成的依赖产物；真正需关注的是composer.lock是否提交且与composer.json一致，否则会导致环境不一致。
Composer 没有 status 命令能定位“被 Git 误忽略的 vendor 组件”——因为 vendor 本就不该被 Git 跟踪，所谓“误忽略”根本不存在；真出问题，是 composer.lock 没提交或已损坏。
为什么 composer status 不存在且不解决你的实际问题
Composer 官方命令列表里没有 status。有人误以为它像 git status 那样能报告 vendor 状态，但 vendor 是构建产物，不是源码，Git 忽略它完全正确。你真正遇到的“vendor 找不到”“类加载失败”“包缺失”，99% 源于以下三者之一：
-
composer.lock文件未提交到 Git，或被本地修改（比如换行符差异、手动编辑） -
composer.lock和composer.json版本约束脱节，导致 install 时退化为 update 行为 - CI 或新环境没运行
composer install，只靠 Git 克隆代码，自然没有 vendor
用 git status + composer show 快速验证 vendor 是否“完整”
想确认当前 vendor 是否和 lock 文件一致，别猜，直接比对：
- 运行
git status --ignored：如果输出里出现vendor/目录，说明它被意外加入 Git（.gitignore没生效或漏写了/vendor/） - 运行
composer show --installed | wc -l：得到已安装包数量；再对比composer show --locked | wc -l（需 Composer 2.2+），两者数字必须相等 - 挑一个关键包（如
monolog/monolog），分别运行：composer show monolog/monolog --version（查 vendor 实际装的版本）composer show --locked monolog/monolog --version（查 lock 记录的版本）——必须一致
当 git status 显示 vendor 被修改，说明 .gitignore 失效了
这是最常被忽视的配置错误：vendor 目录出现在 git status 输出中，意味着 Git 正在跟踪它。原因几乎总是 .gitignore 写错了：
- 写成了
vendor（没加开头斜杠）→ 会匹配src/vendor_api/、myvendor.php，同时漏掉根目录vendor/ - 正确写法必须是
/vendor/（结尾斜杠可选，但推荐加，语义更清晰） - 改完
.gitignore后，必须立刻执行git rm -r --cached vendor清除索引缓存，否则git status仍显示它 - 别忘了同步忽略
vendor/bin/和composer.phar，它们同样不该进 Git
真正需要关注的“状态”其实是 composer.lock 的完整性
vendor 可以随时删掉重装，但 composer.lock 一旦损坏或丢失，就失去了可重现性保障。每次操作前快速检查这三点：
- 运行
composer validate：确认composer.json和composer.lock语法合法、结构兼容 - 运行
git ls-files | grep "^composer\.lock$"：确保它在 Git 索引里，且没被标记为 modified - 在 CI 脚本开头加
test -f composer.lock || { echo "FATAL: composer.lock missing"; exit 1; }
复杂点在于：composer.lock 不是“静态快照”，它依赖所有包源（Packagist、私有 repo、GitHub 分支）在那一刻的可用性。哪怕 .gitignore 和 git status 看起来都干净，只要某个包源返回 404 或权限拒绝，composer install 就会中断——这不是 vendor 的问题，是协作链路上的单点故障。
