composer config discard-changes true 不会处理脏状态，仅在 composer update/install 重装非 path 类型包时自动丢弃未跟踪的本地修改；若包为 path 类型、.git 损坏、修改已 git add 或执行非重装命令（如 dump-autoload），则该配置不生效。
直接说结论： composer config discard-changes true 不会“处理”脏状态，它只是让 Composer 在更新时自动丢弃你对 vendor 里依赖包的本地修改——但前提是这些修改没被 git 跟踪，且你执行的是 composer update 或 composer install（且锁文件允许变更）。
为什么 discard-changes true 看似没生效？
常见现象是：你改了 vendor/some/package/src/Helper.php，运行 composer update 后文件还在，没被还原。这是因为：
-
discard-changes只影响composer update和composer install过程中对已安装包的“重写”行为，不触发git checkout --force式的强制清理 - 如果该包是通过
path仓库类型引入的（比如"type": "path"），Composer 默认跳过 discard 逻辑 - 如果包目录下存在未提交的 git 更改但 git 状态为 “dirty”，而 Composer 检测到其 .git 目录完好，它可能仍尝试
git reset --hard；但若 .git 损坏、或包根本没用 git（如 zip 包安装），此配置无效 -
composer dump-autoload、composer require（不触发重装）等命令完全不读取该配置
真正触发 discard 的典型场景和操作
只有当 Composer 需要“重新获取并解压/clone”某个包时，才会检查 discard-changes 并决定是否覆盖本地改动。关键条件包括：
- 该包在
composer.lock中的版本号/commit hash 发生变化（composer update或手动改了require） - 包不是
path类型，且安装方式为git或zip - 本地修改未被
git add或已git stash——否则 git 操作可能失败，导致整个更新中断
验证是否启用成功：
git-staged-commit-message
下载
仅从仓库的暂存文件生成 Git 提交消息。当用户要求 Codex 根据暂存更改、缓存差异、Git 索引或已通过 `git add` 添加的文件来编写、起草、创建或建议提交消息时使用；切勿代表用户执行提交操作。
composer config discard-changes
应输出 true；若为空，说明未生效（可能在全局配置而非项目级，或拼写错误为 discard_changes）。
比 discard-changes 更可靠的手动清理方式
当你要确保 vendor 干净，尤其面对持续出现的脏状态时，依赖配置不如明确执行：
- 删掉整个
vendor/目录再composer install——最彻底，但慢 - 对单个包强制重装：
composer reinstall vendor/package-name（需 Composer 2.2+） - 用 git 手动清理（适用于 git 安装的包）：
cd vendor/package-name && git reset --hard && git clean -fdx
- 禁止本地修改依赖的惯性做法：把补丁转成
patches（用cweagans/composer-patches），或提 PR 到上游，而不是直接改 vendor
真正麻烦的从来不是配置开关，而是那些没进 git、没写文档、只在某次调试中随手改了两行的 vendor 文件——它们不会被 discard-changes 拦住，也不会出现在任何 diff 里，直到某天 CI 环境崩掉才暴露出来。
