discard changes提示是composer的保护机制，非错误；仅当你手动修改vendor文件且其哈希与composer.lock不一致时触发，目的是阻止意外覆盖，而非解决依赖冲突。

直接在 vendor/ 里改代码，composer install 就会提示 Discard changes ——这不是 bug，是 Composer 在拦你别把临时 patch 当正式方案用。真想保留修改，必须绕过 vendor/ 目录本身。

为什么 Discard changes 提示不是错误，而是保护机制

这个提示只在一种情况下出现：你手动编辑过 vendor/some/package/src/Helper.php 这类文件，且该包当前内容的哈希值与 composer.lock 记录的不一致。Composer 准备用锁文件指定的内容覆盖它，所以停下来问你要不要丢。

• 它和依赖解析、版本冲突完全无关，删 vendor/ 或 composer.lock 不解决它
• "discard-changes": true 或 composer install -n 只是跳过确认，你的修改依然会被删
• Git 不跟踪 vendor/，CI 构建必失败，协作时别人机器上根本没你那几行

真正可落地的两个替代方案

Composer 明确把 vendor/ 当作只读缓存区。要让修改长期生效、可复现、能协作，只有两条路：

• path 仓库映射：把包复制到项目外（如 ../my-patch-for-guzzle），在 composer.json 的 repositories 里加 {"type": "path", "url": "../my-patch-for-guzzle"}，再把 require 中的版本改成 "dev-main as 7.5.0"（假设原版是 7.5.0）
• package 仓库伪造：把你改好的代码打成 zip，上传到私有地址（如内网 NAS），在 repositories 里声明 {"type": "package", "package": {"name": "guzzlehttp/guzzle", "version": "7.5.0-patched", "dist": {"url": "https://intranet.example.com/guzzle-7.5.0-patched.zip", "type": "zip"}}

前者适合本地调试，后者适合打包分发。两者都让 Composer 把你的修改当“正式发布版”装，不会被覆盖。

First Principles Decomposer

把任何问题拆解为根本真理，再从原子层面重建解决方案。

下载

已经改了 vendor/，怎么抢救

如果修改已存在但还没提交、也没备份，立刻执行：

• 运行 git status 看是否在 Git 工作区（通常不在，因为 vendor/ 被 .gitignore 了）
• 用 diff -r vendor/original-package/ /tmp/saved-copy/ 对比临时备份（如果你有）
• 没有备份？马上把改过的文件复制出来，再跑 composer install -n 恢复干净状态，然后走上面的 path 或 package 方案重做

别指望 composer.lock 能帮你找回修改——它只存哈希，不存内容。

最常被忽略的一点：所有方案都要求你把修改逻辑从 vendor/ 移到可版本管理的位置。否则，哪怕用了 path，只要路径没进 Git 或没同步给队友，问题就还在。