Composer 没有 discard-changes 命令，因 vendor/ 是只读依赖目录，手动修改违背规范；应通过 rm -rf vendor/ && composer install 彻底重装，或用 patch 管理工具替代直接修改。
composer discard-changes 并不是 Composer 的内置命令——它根本不存在。你执行时会看到 Command "discard-changes" is not defined，这是最常踩的第一个坑。
为什么没有 discard-changes？
Composer 本身不提供“丢弃 vendor 目录修改”的专用命令，因为 vendor/ 是只读的依赖快照目录，按设计就不该手动修改。一旦改了，说明流程已偏离规范：
- 你可能在调试时直接改了某个包的源码（比如临时加
var_dump） - 你误把
vendor/当成可编辑工作区 - 你想快速回退某次 patch 或本地 patch 导致的脏状态
真正有效的替代方案
根据你的实际场景，选下面一种：
- 如果只是想还原被你手动改过的文件：
git checkout -- vendor/（前提是vendor/在 Git 里被跟踪了——但通常不建议这么做） - 更安全通用的做法：
rm -rf vendor/ && composer install。这是最干净、无副作用的方式，尤其适合 CI 或本地环境重置 - 如果你用的是
composer install --no-dev等定制参数，记得复用相同参数重装，否则行为可能不一致 - 若你用
patch或composer-patches插件打了补丁，要丢弃修改得先删补丁配置，再重装
怎么避免下次再想“丢弃 vendor 修改”
根本解法是把调试和定制逻辑移出 vendor/：
- 调试第三方包？用 Xdebug 断点，或写个本地 wrapper 类去继承/装饰，而不是改源码
- 需要定制行为？通过事件监听（如 Laravel 的
Event::listen）、中间件、或 fork 包 +repositories指向你的分支 - 临时 hack 必须存在？把 patch 文件放在项目根目录，用
composer-patches管理，而非直改vendor/
真正麻烦的从来不是“怎么丢弃”，而是 vendor 被改之后，你不确定哪些改动是临时调试留下的、哪些是忘了提交的 patch、哪些是其他协作者悄悄加的——这种模糊性才是最耗时间的。
