Composer不小心改了Vendor源码？一键恢复原始状态【指南】-composer-PHP中文网

vendor目录不是代码工作区，手动修改必被覆盖或报错；恢复唯一可靠方式是删除整个vendor目录后执行composer install。

composer不小心改了vendor源码？一键恢复原始状态【指南】

直接说结论：vendor 目录不是你的代码工作区，任何手动修改都会被 composer install 或 composer update 覆盖或引发冲突；恢复原始状态最可靠的方式是删掉整个 vendor 目录 + 重新安装，而不是“找差异”或“回退单个文件”。

为什么不能手动改 vendor 里的代码？

Composer 管理的包是「只读快照」——它按 composer.lock 中记录的精确版本、哈希和安装路径解压/软链。你改了某个 vendor/some/package/src/Helper.php，下次运行 composer install 时：

如果 lock 文件没变，Composer 会校验文件哈希，发现不一致就报错：Package some/package has modified files
如果 lock 文件被更新过（比如别人 push 了新 commit），你的修改会被直接覆盖，且毫无提示
Git 会把 vendor/ 当作普通目录跟踪（除非你加了 /vendor/ 到 .gitignore），导致提交污染、PR 混乱、CI 失败

删 vendor + 重装是最稳的恢复方式

别试图用 git checkout vendor/xxx 或比对 diff —— 大多数包根本没在 vendor 目录里初始化 Git 仓库，git 命令压根不生效。正确操作只有三步：

确认当前项目根目录下有有效的 composer.lock（没有就先 composer update --lock 生成一份）
执行 rm -rf vendor/（Linux/macOS）或 rmdir /s vendor（Windows CMD），确保彻底清空
运行 composer install（不是 update），它会严格按 composer.lock 还原所有包的原始状态

注意：composer install 不会升级包版本，也不会改 lock 文件，这才是「恢复」该有的行为。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

想临时改包逻辑？用 patch 或 override，别碰 vendor

真有定制需求（比如修一个未发版的 bug），应该走可维护方案：

用 composer-patches 插件管理补丁文件，写好 .patch 放项目里，composer install 自动打上
通过 Composer 的 repositories 配置，把包指向你 fork 后修复的 GitHub 分支，再 composer require "vendor/name:dev-fix-branch"
如果是 Laravel 项目，优先用 Service Provider 或 Facade 替换绑定，而不是改 vendor/laravel/framework/src/...

这些方式都能被 Git 跟踪、被团队共享、被 CI 复现 —— 手动改 vendor 是唯一既不可逆又不可协作的路。