buffalo项目依赖损坏需三步修复：删go.sum和vendor目录、确保cli版本与go.mod中buffalo版本一致、清理cgo缓存并重装pop/v6及数据库驱动，最后执行go mod verify校验。
Buffalo 项目核心依赖损坏时，不能只跑 go mod tidy 或重装 CLI 就完事——buffalo dev 启动失败、buffalo db migrate panic、甚至 go build 报找不到 github.com/gobuffalo/buffalo，往往是因为 Go 模块缓存、本地 vendor 冲突或 Buffalo CLI 版本与项目生成器不匹配这三处出了问题。
删干净 go.sum 和 vendor（如果存在）
Go 的模块校验机制会让损坏的依赖“卡死”在 go.sum 里，哪怕你改了 go.mod，go mod tidy 也可能复用旧哈希。vendor 目录更危险：它会绕过模块代理，直接锁定坏掉的 commit。
- 执行
rm go.sum（不要只改内容，必须删文件） - 如果有
vendor/目录，直接rm -rf vendor；别想着保留部分依赖 - 再跑
go mod tidy -v，加-v能看到真实拉取路径，确认是否命中 proxy.golang.org 或私有 registry
检查 buffalo CLI 是否和项目生成版本一致
Buffalo CLI 不是“一次安装终身可用”。v0.18.x 生成的项目用 v0.17.x 的 CLI 运行，可能因 pop/v6 驱动签名变更导致 buffalo db create 报 unsupported driver；反过来，v0.17 项目被 v0.18 CLI 初始化，又可能把 actions/app.go 里的中间件顺序搞乱。
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 运行
buffalo version，对比项目根目录下go.mod中github.com/gobuffalo/buffalo的版本（如v0.18.3） - 不一致就重装 CLI：
GO111MODULE=on go install github.com/gobuffalo/buffalo/v2@v0.18.3（把v0.18.3换成你项目实际需要的版本） - 注意：不要用
brew install buffalo或二进制下载，它们更新滞后且不区分 major 版本
强制刷新 pop 和 database 驱动
最常出问题的是 github.com/gobuffalo/pop/v6 及其底层驱动（github.com/lib/pq、mattn/go-sqlite3）。SQLite 编译失败、PostgreSQL 连接池 panic，90% 是驱动没重新 build。
- 先清理 CGO 缓存：
go clean -cache -modcache - 对 SQLite 项目，确保系统有
gcc，然后跑：CGO_ENABLED=1 go mod tidy（禁用 CGO 会导致 sqlite3 驱动加载失败） - 对 PostgreSQL，删掉
go/pkg/mod/cache下所有lib/pq@相关目录，再go mod tidy，避免旧版驱动残留 - 验证驱动是否生效：在
models/models.go里临时加一行log.Printf("driver: %v", sql.Drivers())，启动时看输出是否含postgres或sqlite3
真正麻烦的不是重装，而是你删了 go.sum 却忘了 go mod verify 校验失败时的静默忽略——它不会报错，但后续任何 go build 都可能偷偷用错版本。每次 tidy 后，务必手动执行一次 go mod verify 确认无误。
