buffalo项目依赖管理完全由go modules统一控制，go.mod和go.sum是唯一权威来源；buffalo dev等命令不修改依赖，自动拉取实为go工具链隐式行为，需手动go get加版本后go mod tidy确保一致性。
Buffalo 项目依赖管理只用 Go Modules，不用 buffalo-plugins 或其他封装
Buffalo 自 2021 年起就完全放弃自研依赖管理工具（如旧版 buffalo-pop 的 vendor 模式），所有依赖统一由 Go 官方 go mod 控制。你看到的 go.mod 和 go.sum 就是唯一权威来源，buffalo dev 或 buffalo build 均不修改或绕过它。
常见错误现象：有人执行 buffalo generate resource user 后发现 models/user.go 编译报错 “undefined: pop”，其实是 github.com/gobuffalo/pop/v6 没加进 go.mod——Buffalo 不会自动 go get 任何包。
- 添加依赖必须显式运行
go get github.com/gobuffalo/pop/v6（或对应版本），不能靠 Buffalo 命令触发 - 若项目禁用 pop（比如只用 sqlx 或 pgx），直接删掉
actions/app.go中的app.Use(pop.Transaction(app.DB))，再go mod tidy清理残留 -
buffalo plugins list显示的插件只是 CLI 工具链扩展，和运行时依赖无关；它们不写入go.mod，也不影响二进制构建
为什么 buffalo dev 有时会“偷偷”拉取依赖？
这不是 Buffalo 的行为，而是 Go 工具链在特定场景下的隐式动作：当你运行 buffalo dev，它底层调用 go run main.go，而 Go 在编译时发现 go.mod 缺少某包的 require 条目，就会自动 go get 并更新 go.mod。这容易让人误以为 Buffalo 在管理依赖。
这种自动拉取有风险：
- 可能拉到非预期版本（比如
go get默认 latest，而非go.mod锁定的版本） - CI/CD 流水线中因环境差异导致
go.mod被意外修改，引发构建不一致 - 与
go mod vendor冲突：vendor 目录存在时，Go 仍可能尝试联网获取新包
建议始终先手动 go get 明确版本，再 go mod tidy，最后运行 buffalo dev。
第三方插件（如 buffalo-goth）的依赖怎么处理？
这类插件本质是普通 Go 包，安装方式和其他库完全一致：运行 go get github.com/gobuffalo/buffalo-goth，然后在 actions/app.go 中 import 并注册中间件。Buffalo 不提供插件专属的依赖注入机制。
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
注意两个易踩坑点：
- 插件文档里写的
buffalo plugin install xxx是过时命令（2022 年归档前遗留），现在已失效，执行会报command not found - 某些插件（如旧版
buffalo-auth）依赖已废弃的gobuffalo/mw-csrf，需手动替换为github.com/gorilla/csrf并调整初始化代码 - 插件的
go.mod版本声明可能与你的项目冲突（例如要求go 1.20，而你用1.22），此时需用replace重定向：replace github.com/gobuffalo/buffalo-goth => ./local-fixes/buffalo-goth
依赖冲突时，go mod graph 比 Buffalo 日志更有用
Buffalo 启动失败时，错误堆栈常被中间件 recovery 捕获，掩盖真实依赖问题。比如 panic: interface conversion: interface {} is nil, not *pop.Connection 看似是 pop 初始化失败，实际可能是 github.com/gobuffalo/pop/v6 和 github.com/gobuffalo/pop/v5 同时被间接引入。
直接运行以下命令定位冲突：
go mod graph | grep pop
输出会列出所有 pop 相关依赖路径，快速识别是否混用 v5/v6。修复后务必 go mod tidy && go mod verify，避免 go.sum 校验失败。
Buffalo 本身不提供依赖图谱或冲突检测能力，它的职责止于路由和中间件编排——依赖这件事，得交给 Go Modules 自己管到底。
