不能直接发现。composer status仅比对source模式安装包的文件哈希与composer.lock记录值，不检查逻辑、不运行代码、也不验证行为变化；update后功能异常但status显示clean，说明问题在bc break、配置不适配或缓存未清，而非vendor被篡改。
composer status 能不能发现 update 后的代码异常？
不能直接发现。它只比对 vendor/ 目录下 source 模式安装包的文件哈希与 composer.lock 记录值，不检查逻辑、不运行代码、也不验证行为是否变化。如果你 composer update 后功能出错，但 composer status 显示 clean，说明问题不在 vendor 文件被篡改——更可能是：依赖版本升级引入了 BC break、配置未适配新接口、或缓存未清（比如 Laravel 的 config cache 或 Doctrine proxy cache）。
为什么 update 后 status 还是 clean，但实际行为变了？
因为 composer status 默认只扫描 source 模式安装的包（即含 .git 目录），而绝大多数包走的是 --prefer-dist（zip 解压），根本没 .git，status 直接跳过校验。所以即使你刚 update 了 symfony/http-foundation 到 v6.4，只要它是 dist 模式安装，status 就不会管它有没有变。
- 确认包安装模式：
composer show symfony/http-foundation，看输出里有没有source字段 - 想让 status 生效，必须先切到 source：
composer update --prefer-source symfony/http-foundation - 切完还得重跑
composer status，否则缓存可能仍返回旧结果
status 和 update 的关系到底是什么？
composer status 是只读快照比对，composer update 是重算+重装+重写 lock。两者目的完全不同，不能互相替代，也不能用 status 结果反推 update 是否成功。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- status 显示 modified ≠ update 出错，只说明 vendor 里某个 source 包被手动改过（比如加了
var_dump） - status 显示 clean ≠ update 没问题，只说明 source 包没被改，dist 包和 runtime 行为完全不在它的检测范围内
- 真正要验证 update 效果，得靠测试用例、日志观察、或
composer show看实际安装版本
排查 update 导致的 Bug 时，status 最实用的场景
它唯一不可替代的价值，是快速排除“有人手改 vendor”这个干扰项。比如 CI 构建失败，你怀疑是不是某人调试时在 vendor/doctrine/dbal 里加了临时 patch 却忘了删。
- 先跑
composer status -v：如果有 output，说明至少有一个 source 包被改，得进对应目录查git diff - 如果静默无输出，基本可排除 vendor 被手动污染，问题转向依赖兼容性、环境变量、或缓存
- 注意：某些包（如 Doctrine Proxy、Laravel Octane 的生成类）每次运行都会动态改文件，status 必然报 modified——这不是 bug，是预期行为
真正复杂的地方在于，status 的“clean”结论只覆盖极小一部分 vendor，而多数真实问题藏在 dist 包的行为变更里。别让它误导你忽略版本差异本身。
