Composer默认拒绝覆盖手动修改的vendor文件，discard-changes是需显式启用的运行时策略而非开关；报错“The package has modified files”是因检测到未提交的本地改动且锁文件版本变更，为防代码丢失而中止执行。
直接说结论：Composer 默认拒绝覆盖你手动改过的 vendor 文件，discard-changes 不是开关，而是策略选项，必须配合 composer install 或 composer update 显式启用，否则你的本地修改会卡住命令执行。
为什么 composer install 突然报错 “The package has modified files”
这是 Composer 在保护你——它检测到某个 vendor 包（比如 monolog/monolog）里有未提交的本地改动（比如你临时加了 var_dump 或改了逻辑），而当前要安装的锁文件版本和上次不一致，它不敢自动覆盖，怕丢代码。
常见触发场景：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 你在
vendor/some/package/src/Helper.php里加了调试代码，忘了还原 - 用 IDE 直接在 vendor 里修 bug，没提 PR，也没用 patch 文件管理
- 团队协作中有人 commit 了改过的 vendor，别人
composer install就卡住
discard-changes 怎么用才生效
它不是配置项，不能写进 composer.json 或 config.json 永久开启。它是运行时 flag，只对当次命令起作用：
-
composer install --discard-changes：跳过所有 vendor 修改检查，强制按composer.lock覆盖 -
composer update --discard-changes：更新时也忽略本地改动，直接拉新版本 - ⚠️ 注意：
--no-interaction必须一起用，否则遇到冲突仍会停住等你选（比如composer install --discard-changes --no-interaction） - 它不会删你改的代码——而是直接用远程包覆盖整个目录，所以你那些改动就丢了
比 --discard-changes 更安全的替代方案
硬覆盖只是“快”，不是“对”。真要改 vendor 包，应该走可维护路径：
- 用
composer patch（需插件如cweagans/composer-patches）把修改做成补丁，声明在composer.json里 - fork 包仓库 → 改代码 → 提 PR → 用
"repositories"指向你的 fork 分支，比如："repositories": [{"type": "vcs", "url": "https://github.com/yourname/monolog"}] - 如果是调试需要，改完立刻
git checkout -- vendor/some/package还原，别留脏状态 - CI 环境务必加
--no-interaction --discard-changes，但开发机建议禁用，逼自己走正路
真正麻烦的从来不是怎么绕过提示，而是改完 vendor 后没人知道那行 dump($x) 是谁加的、为什么加、会不会影响下次更新——这些细节，--discard-changes 从不提醒你。
