discard-changes 是强制重置指令，非开关：它忽略 vendor 未提交修改，按 composer.lock 全量还原，不备份、不提示；composer install 卡在“the package has modified files”是因 composer 主动中止检测到 git 仓库内任意已修改文件。
discard-changes 不是开关，而是强制重置指令：它让 Composer 忽略 vendor 目录下所有未提交的本地修改，并按 composer.lock 全量还原对应包——改过的代码直接消失，不备份、不提示、不暂存。
为什么 composer install 突然卡在 “The package has modified files”
这是 Composer 主动中止，不是网络或权限问题。它扫描 vendor/ 下每个包，只要发现含 .git 且 git status --porcelain 有输出（哪怕只是多了一个 debug.log），就拒绝继续。
- 典型触发点：
vendor/monolog/monolog/src/Logger.php里加了var_dump($context)没还原 - IDE 直接双击打开
vendor/文件并保存，Git 自动标记为 modified - CI 构建机缓存了带临时 patch 的
vendor/，下次install就撞上 - 它不区分“改的是 README 还是核心逻辑”，只要在 Git 仓库里，就一视同仁
--discard-changes 和 "discard-changes": false 完全是两回事
前者是命令行参数，后者是项目配置项，行为截然相反：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer install --discard-changes：跳过检查，直接执行git reset --hard && git clean -fdx，删掉所有未提交改动 -
"discard-changes": false写进composer.json的config段：检测到修改时立刻报错退出，错误信息类似Changed files in vendor/package-name will be discarded. Use --force to overwrite. -
composer config discard-changes false有效；composer config -g discard-changes false无效，全局配置被忽略 - 两者都不支持
stash或backup—— Composer 从不保存你改过什么
CI 环境必须加 --no-interaction --discard-changes
自动化流程里出现交互式提示 [y,n,v,d,s,?] 就等于卡死。但仅加 --discard-changes 不够，因为某些冲突场景仍会停住等你选：
-
composer install --discard-changes --no-interaction：安全组合，CI 脚本应固定使用 -
composer update --discard-changes --no-interaction：慎用，它会先更新composer.lock再丢弃修改，可能引入非预期变更 - 不要在开发机长期启用
--discard-changes：它掩盖问题，让你忘了“谁在 vendor 里加了那行dump()”，也绕过了补丁管理的必要性
真正该做的不是绕过提示，而是让修改可追踪
靠 --discard-changes 只能解决“这次跑通”，但解决不了“下次谁来维护这行魔改”。实际项目里更可靠的做法是：
- 用
cweagans/composer-patches插件，把修改写成.patch文件，声明在extra.patches里 - fork 原包 → 提交修改 → 在
composer.json的repositories里指向你的分支 - 对调试用的临时修改，执行完立刻
git checkout -- vendor/package还原，别留脏状态 - 如果包是
"type": "path"，Composer 默认跳过修改检查——这正是为本地开发定制留的后门
最麻烦的从来不是命令加不加 --discard-changes，而是没人知道 vendor/symfony/http-foundation/Request.php 第 421 行那个 return true; 是谁改的、为什么改、要不要合进主干。
