composer status空输出不表示vendor未被修改，仅说明source模式安装的包未改动；默认prefer-dist导致90%包走zip安装、无.git目录，故不被扫描——空输出≠干净，只是未检查到source包改动。
它不能帮你复现 Bug，但能帮你确认“这个 vendor 目录到底还是不是当初那个”——这是现场保护的第一道防线。
为什么 status 输出为空，却不能说明第三方库没被改过
composer status 只比对 composer.lock 中记录的哈希值与当前 vendor/ 下实际文件的哈希值，但它只对以 --prefer-source 方式安装的包生效。默认 prefer-dist: true 下，90% 的包是 zip 解压安装的，vendor/monolog/monolog 里根本没有 .git 目录，status 直接跳过——空输出 ≠ 干净，只是“没检查到 source 包的改动”。
- 用
composer show monolog/monolog查看输出：若没有source字段，说明它是 dist 模式，status 对它完全静音 - 私有包若漏配
"type": "package"或没声明"source"，即使你本地有 Git 仓库，Composer 也不会识别 - CI 流程中看到
composer status无输出就认为“环境干净”，很可能漏掉大量 dist 包的意外修改（比如手动 patch、脚本生成临时文件）
status 报 modified，但你根本没动代码？这很常见
报 modified 不等于你手改了源码。很多包在安装后会执行 post-install-cmd，比如 Symfony 写缓存、Laravel 生成 storage/framework/views、Doctrine 生成代理类——这些路径若没被 .gitignore 覆盖，就会被 status 当作“被篡改”。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer status -v看具体哪些文件被标为 modified，常会发现是vendor/symfony/cache/Adapter/ProxyAdapter.php这类自动生成文件 - 如果之前用
composer install --no-scripts装过，某些 post-install 逻辑没执行，导致文件缺失，也会被识别为 “modified” - status 不区分“用户修改”和“包自身生成”，它只认哈希不匹配——这点必须心里有数，否则容易误判现场污染程度
想让 status 真正覆盖你想查的包，只有一个办法
把目标包强制切到 source 模式。dist 包不会自动转换，必须重装。
- 删掉该包：
composer remove monolog/monolog - 重新安装并指定 source：
composer require monolog/monolog --prefer-source - 验证是否生效：
ls -a vendor/monolog/monolog/.git应该存在；再跑composer status就能真正监控它的改动了 - 注意：这个操作只影响单个包，不影响其他依赖；但若项目里大量用 path repo 或本地开发包，它们默认也不被 status 扫描，需单独处理
现场保护的关键动作其实是“快照 + 隔离”
status 是轻量级验证，但它本身不保存状态。真要保护现场，得配合 composer.lock 和 Git：
-
composer.lock是唯一权威快照，它包含每个包的精确版本、哈希、子依赖树——只要它没被改，composer install就能还原当时状态 - 不要复制
composer.lock成lock-backup.json，Git tag 更可靠：git tag lock-bug-repro-20260617 - 如果 Bug 只在某次 CI 构建中出现，直接
git checkout lock-bug-repro-20260617 -- composer.lock && composer install，就能重建那个“疑似被污染”的现场 - status 在这里的作用，是快速回答一个问题：“现在这个 vendor，是不是跟 tag 里的 lock 完全一致？”——答案是，才敢往下 debug；不是，就得先清理再重来
