vendor目录不是代码工作区，手动修改必被覆盖或报错；恢复唯一可靠方式是删除整个vendor目录后执行composer install。
直接说结论：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）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “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 是唯一既不可逆又不可协作的路。
顺手检查这三件事，避免下次踩坑
恢复完别急着写代码，花 30 秒确认：
-
.gitignore里是否包含/vendor/（没有就加上，否则下次git add .又会误提交） -
composer.json中是否启用了"config": {"secure-http": true}（防止从 HTTP 源拉取被篡改的包） - 有没有把调试用的
var_dump()或dd()留在 vendor 文件里（它们不会报错，但可能卡住生产环境）
vendor 是 Composer 给你搭的「集装箱」，你负责调度，不负责焊接焊缝。改错了就拆了重装，别拿胶带缠。
