Buffalo纯API需三步精简：删templates/assets等目录、禁用cookies/CSRF/session中间件、改用c.JSON()和显式路由；否则易panic或返回空响应。
Buffalo 不是“开箱即用”的纯 REST API 框架，buffalo new --api 生成的项目默认仍含大量前端和数据库耦合逻辑；想快速跑通一个轻量、可调试、不卡壳的 JSON API，必须在初始化后立即做三件事：删目录、关中间件、换路由写法。
删掉 templates/ 和 assets/ 目录再启动
Buffalo 的 c.Render() 默认会 fallback 到 HTML 模板，哪怕你只调 c.JSON()，只要 templates/ 目录存在，它就可能因找不到 application.plush.html 而 panic 或返回空响应。assets/ 同理——它会触发 Webpack 构建监听，拖慢启动、干扰热重载。
- 执行
rm -rf templates/ assets/ public/ node_modules/ - 检查
app.go中是否还有app.ServeFiles()或plugins.Static()调用，全部注释掉 - 运行
go mod tidy清理掉 plush、packr/v2 等模板相关依赖
禁用 cookies、CSRF、session 等浏览器中间件
这些中间件在纯 API 场景下不仅无用，还会因缺少 store 或 header 校验直接返回 403/500。Buffalo 不会自动跳过它们，必须手动剥离。
- 找到
app.Use(cookies.Secure())、app.Use(csrf.New())、app.Use(session.Middleware())，全部注释或删除 - 确认
middleware.Defaults()里没隐式加载这些——它只是个 convenience wrapper，实际内容得看源码或文档 - 保留
logger.RequestLogger和request_id.Middleware这类对调试有用的中间件
用 c.JSON() 替代 c.Render()，显式注册 app.GET()
c.Render(200, r.JSON(data)) 看似简洁，实则绕了渲染器链，容易因未初始化 template loader 报错；而 app.Resource() 自动生成的 REST 路由会绑一堆 pop.Transaction、auth_required 等中间件，你根本不需要。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- handler 写法改用：
return c.JSON(200, map[string]string{"status": "ok"}) - 路由注册改用显式
app.GET("/api/ping", PingHandler)，别碰app.Resource() - 如果要用版本前缀（如
/api/v1/），定义常量const PingPath = "/api/v1/ping"，避免字符串散落
开发阶段优先用 go run main.go 而非 buffalo dev
buffalo dev 的热重载依赖内部 watcher 和插件系统，一旦你删了 assets/ 和 templates/，它反而容易卡在 asset 构建或模板加载环节；而 go run main.go 更贴近真实运行态，panic 堆栈清晰、无中间件吞错误、build 流程可预测。
- 改完 handler 后手动
Ctrl+C+go run main.go，比等 buffalo dev 重载更快 - 调试时能直接看到原始 panic，不会被 Buffalo 的 recovery 中间件包一层再吐出 generic error
- 若需环境变量（如
DATABASE_URL），用DATABASE_URL=... go run main.go显式传入，不依赖 .env 文件
真正麻烦的不是写 handler，而是 Buffalo 默认把所有东西都“连在一起”——删一个目录可能影响中间件加载顺序，关一个中间件可能让 logger 失效，甚至 go mod tidy 都可能因为残留的 plush import 导致编译失败。动手前先 git status 看一眼初始状态，删之前 ls -a 确认 templates/ assets/ 是否真的空，比事后 debug 快得多。
