buffalo new生成的项目不是开箱即用的Web项目，而是含Webpack、Plush模板、Favicon、Static服务、Session及CSRF等强耦合组件的全栈骨架，需立即删减assets/、templates/、禁用模板与静态中间件、移除plush/packr依赖，并显式声明路由与JSON响应，否则build卡死、dev报错、渲染异常。
直接用 buffalo new 创建的项目不是“开箱即用”的 Web 项目，而是带强耦合前端构建、模板渲染和默认中间件的全栈骨架——你得立刻删减、重配、绕过默认流程，否则连 buffalo build 都会卡死。
buffalo new 生成的项目为什么不能直接跑起来？
它默认启用 Webpack 构建、Plush 模板、Favicon 中间件、Static 文件服务、Session 和 CSRF，哪怕你只想要一个纯 JSON API，这些组件也照常加载。常见现象包括：
-
buffalo dev启动后访问/返回 500，日志里出现template: index.html:1:1: executing "index.html" at <.>: nil pointer</.> -
buffalo build卡在building assets...阶段，不报错也不退出 - 调用
c.Render(200, r.JSON(...))却返回 HTML 页面，因为模板中间件劫持了响应
删减冗余组件的实操清单
进入项目根目录后，必须立即执行以下操作，顺序不能错：
- 删掉
assets/目录（Webpack 构建入口）和webpack.config.js（否则buffalo build仍会尝试编译） - 注释或删除
app.Use(plugins.Favicon())和app.Use(plugins.Static())（API 不该暴露静态文件） - 清空
templates/下所有文件，并在app.go中设app.Templates = nil（禁用模板引擎） - 检查
go.mod，移除github.com/gobuffalo/plush和github.com/gobuffalo/packr/v2（纯 JSON API 不需要） - 确认
database.yml存在但未被pop加载——如果不用 DB，就别调pop.Connect()
路由与 handler 必须显式声明，别信自动生成
buffalo g resource users 会生成一堆 CRUD 路由和模板代码，但 BFF 或 API 场景下你根本不需要 UsersNew 或 UsersEdit 这类 handler。正确做法是：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 手动在
routes/app.go中写app.GET("/api/v1/status", StatusHandler)，路径带版本前缀 - handler 函数签名保持标准：
func StatusHandler(c buffalo.Context) error - 返回 JSON 时用
c.JSON(200, map[string]string{"status": "ok"})，别用c.Render()（已禁模板） - 若需复用中间件（如日志、JWT 鉴权），用
app.Use(MiddlewareFunc)显式注册，别依赖middleware.Automatic
开发阶段用 go run main.go，别依赖 buffalo dev
buffalo dev 的热重载机制会偷偷触发 asset 编译、模板 reload 和插件初始化，干扰调试。而 go run main.go 更贴近真实运行态：
- 修改 handler 后手动重启，但 panic stack trace 原样输出，不被 Buffalo 的 recovery 中间件吞掉
- 避免因
buffalo-plugins版本不一致导致的 watcher 失效或端口冲突 - 交叉编译时行为可预测：比如
GOOS=linux GOARCH=amd64 go run main.go可直接产出容器可用二进制 - 若实在要热重载，改用
air或fresh，并确保它们监听的是main.go和actions/目录，而非整个项目根
Buffalo 的“快速创建”只体现在脚手架生成速度上，真正能跑通的最小可用项目，必须亲手砍掉一半以上默认功能——尤其是模板、asset、session 和 popORM 这四块，漏掉任意一项，后续都会在构建、部署或联调阶段突然卡住。
