discard-changes是composer的冲突策略而非开关，仅在composer install/update检测到vendor中未提交git修改时触发丢弃重装，默认行为即隐式丢弃；它真正有用场景仅限开发环境临时重置或ci中避免残留修改导致构建失败，不适用于长期补丁管理。
discard-changes 是什么，它在什么场景下真正有用
discard-changes 是 Composer 的一个配置项，作用是在 composer install 或 composer update 时，自动丢弃已安装包中被本地修改过的文件（比如你手动改过 vendor 里的某行代码），而不是报错中断。它不是“帮你保留修改”，而是“帮你跳过冲突、强制回退到原始包内容”——这点很多人一开始理解反了。
典型适用场景只有两个：开发环境临时调试需要快速重置 vendor，或者CI/CD 流水线里避免因残留修改导致构建失败。它不适合长期维护 patch，也不该用于绕过 proper patch 管理流程。
如何启用 discard-changes：全局、项目级与命令行的区别
三种启用方式行为不同，容易混淆：
- 全局设置：
composer config --global discard-changes true—— 所有项目生效，但会掩盖本应被发现的本地修改，不推荐 - 项目级设置：
composer config discard-changes true—— 只影响当前项目composer.json，较安全 - 命令行临时启用：
composer install --discard-changes—— 最可控，尤其适合 CI 脚本或一次性清理
注意：--no-discards 会覆盖配置，强制禁用该行为；如果同时设置了配置又用了 --no-discards，后者优先。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
discard-changes 不处理的情况和常见误判
它只对 vendor/ 下已由 Composer 安装的包内文件生效，以下情况完全不受影响：
- 你新增的文件（如
vendor/package-name/hack.php）不会被删，discard-changes只管“被修改的原始文件” - 使用
path仓库类型（"type": "path"）的包，默认不触发 discard，除非显式加"options": {"symlink": false} - Git dirty state（比如 vendor 目录被 git add 过）可能让 Composer 误判为“非自动管理”，从而跳过 discard
- 错误信息
Cannot apply patch because file has local changes不是discard-changes能解决的——那是 patch 插件的行为，需单独配置patch-ignore或清理 patch 缓存
比 discard-changes 更可持续的替代方案
频繁依赖 discard-changes 往往说明开发流程有问题。更健壮的做法包括：
- 用
composer create-project搭建干净沙箱，而不是直接改 vendor - 对必须定制的包，用
patches（如cweagans/composer-patches）管理变更，可版本化、可复现 - 本地开发用
repositories+path指向 fork 后的本地副本，改完再提交 PR - CI 中统一用
composer install --no-interaction --prefer-dist --ignore-platform-reqs --discard-changes，但仅限部署环节
真正麻烦的不是怎么丢弃修改，而是为什么每次都要丢弃——那通常意味着没把定制逻辑抽离到应用层，或者没建立最小可行补丁验证路径。
