不会。composer 默认不监控 vendor 目录变更，安装后不校验文件完整性，仅依赖 composer.lock 中的 commit hash 或 dist checksum 进行安装，修改后无提示、不还原。
Composer 会主动检测 vendor 文件是否被修改吗？
不会。Composer 默认完全不监控 vendor/ 目录下的文件内容变更，也不在 composer install 或 composer update 时校验已安装包的完整性。它只依赖 composer.lock 中记录的 commit hash（对 Git 包）或 dist checksum（对 ZIP 包）做「安装依据」，但安装完成后就不再比对。
这意味着：你手动改了 vendor/symfony/console/Command.php，Composer 不会报错、不会提醒、也不会自动还原——除非你主动触发校验动作。
怎么快速发现 vendor 里哪些文件被改了？
用 composer show --outdated --direct 看不到这类改动；得靠 Git 配合。前提是你的项目根目录是 Git 仓库，且 vendor/ **没被 .gitignore 排除**（不推荐），或者你临时把 vendor/ 加进暂存区再检查：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 如果
vendor/在.gitignore里（绝大多数项目都是），先运行：git status --ignored=matching -s vendor/
—— 这能列出所有被忽略但实际有变更的文件 - 更直接的办法是进入
vendor/后逐个子目录查：cd vendor/laravel/framework && git status --porcelain
（仅对使用 Git 安装的包有效） - 对 ZIP 方式安装的包（比如
"type": "zip"的 dist 包），Git 无从判断，只能靠人工核对或用composer install --dry-run+ 比较输出来推测异常
如何安全还原被改过的 vendor 文件？
别用 git checkout vendor/ —— 很多包根本不是 Git 克隆来的，而且可能混着 ZIP 和 Git 源。正确做法是让 Composer 重装整个依赖树，但要避免清空全部再装：
- 最稳妥：删掉
vendor/和composer.lock，再跑composer install—— 适合你确认 lock 文件本身没被篡改 - 轻量还原：只删出问题的包目录，例如
rm -rf vendor/my/package，再执行composer install，Composer 会按lock重新拉取该包 - 注意：别用
composer update my/package来“修复”，它可能升级版本，破坏兼容性；update是改依赖，不是修文件
怎样预防下次又手抖改到 vendor？
根本解法不是靠事后补救，而是切断修改路径：
- 编辑器里给
vendor/目录设为「只读」或启用插件（如 VS Code 的Read Only Files扩展），保存时直接报错 - 加 Git 钩子（
.git/hooks/pre-commit），用git diff --quiet vendor/检查，非空则中断提交 —— 能拦住误提交，但拦不住本地改完不提交 - 真要改第三方行为？走正确扩展路径：
service provider、event listener、继承+重写类，而不是直接动vendor/
vendor 就是黑盒。你打开它，就等于自己承担了维护责任——而 Composer 不认这个账。
