composer status 会列出 vendor/ 目录下被修改的第三方包文件，如 vendor/symfony/console/src/Application.php；它通过比对 composer.lock 中记录的原始快照（Git hash 或 checksum）来识别改动，仅检查 vendor 内容，不涉及项目自身代码。
composer status 会列出哪些文件被修改了
composer status 的核心作用是扫描 vendor/ 目录下已安装的包，对比当前文件内容与该包在 composer.lock 中记录的原始安装快照（即 Git commit hash 或 dist zip checksum），找出被本地改动过的文件。
它不会检查你自己的代码，只关注 vendor/ 里的第三方包 —— 比如你手改了 vendor/symfony/console/Application.php，这个命令就会把它列出来。
常见触发场景包括：
- 临时打补丁调试但忘了还原
- IDE 自动格式化了 vendor 里的文件
- 误操作执行了
git checkout或sed -i到 vendor 目录
不加参数时默认只报告“有修改”，不显示详情
运行 composer status 默认只输出类似这样的信息：
Changed files in vendor/symfony/console: src/Application.php src/Command/Command.php
它不会告诉你改了哪几行，也不会标出是新增、删除还是修改。如果想看到具体差异，得加 -v（verbose）参数：
composer status -v
这时会调用系统 git diff（前提是包是以 source 方式安装且带 .git 目录），输出真正的 diff 内容。但注意：dist 安装方式（默认）下即使加 -v 也看不到 diff，只会重复列出文件名。
所以是否能看 diff，取决于：
批量替换指定目录下所有 Git 仓库的远程地址（remote URL）。 当用户需要将 Git 仓库从一个服务器迁移到另一个服务器时使用。 触发词：git remote 替换、git url 批量修改、git 仓库迁移、更换 git 地址、批量修改 remote url。
- 包是否以
"source"模式安装（composer install --prefer-source） - vendor 目录下对应包是否有完整的
.git子目录 - 你的系统是否装了
git命令且在 PATH 中
status 和 update/install 的关系很弱，别指望它帮你修复
composer status 是只读诊断命令，它不会：
- 自动还原任何修改
- 触发重新下载或更新包
- 校验
composer.json和lock是否一致（那是composer validate和composer install --dry-run的事）
如果你发现一堆文件被改了，想恢复原状，得手动操作：
- 删掉整个
vendor/并重跑composer install - 对单个包：进入
vendor/foo/bar，执行git restore .（source 模式）或直接删子目录再composer update foo/bar
注意：有些包（比如 Laravel 的 laravel/framework）在 source 模式下可能没有干净的 git 状态（存在未跟踪文件或本地分支），git restore 可能失败，这时候只能删重装。
CI/CD 里慎用 status 做完整性断言
在 CI 脚本中写 composer status || exit 1 看似能防止 vendor 被污染，但实际容易误报：
- 某些包自带生成文件（如
doctrine/orm的 proxy 类），会被 status 当作“修改” - Windows 下换行符差异（CRLF vs LF）可能导致二进制比对失败
- PHP 扩展差异（如 xdebug 开关）有时会影响 vendor 中某些脚本的输出，间接导致文件内容变化
更稳妥的做法是：在 CI 中跳过 status，改用 composer install --no-dev --optimize-autoloader 保证干净安装；真要校验，优先检查 composer.lock 是否被提交、是否和 composer.json 兼容。
真正需要 status 的时刻，往往是你已经怀疑 vendor 出问题了，而不是拿它当守门员。
