buffalo generate resource 不能直接生成纯 JSON 接口，因其默认绑定 HTML 模板、CSRF、Session 和 DB 事务中间件，且 c.Render() 强制查找模板，删模板即报错，中间件未移除则返回 403/404/500，Content-Type 也非 application/json。
不能用 buffalo generate resource 直接生成“纯 JSON 接口”——它默认绑定 HTML 模板、CSRF、Session 和 DB 事务中间件，不删干净就会报错或返回 404/500。
为什么 buffalo generate resource 生成的接口不能直接返回 JSON
它生成的每个 handler（如 Index、Create）都调用 c.Render()，而该方法默认查找 templates/users/index.html；你删了模板文件，它就报 template: "users/index.html" is undefined。更关键的是中间件链仍在运行：
-
csrf.Middleware强制要求 POST/PUT/DELETE 带 token，前端调用直接 403 -
session.Middleware尝试读写 cookie，API 场景下无意义且可能 panic -
pop.Transaction对每个请求开启 DB 事务，哪怕你根本没碰数据库 - 所有响应 Content-Type 默认是
text/html; charset=utf-8，不是application/json
如何让生成的 resource 支持 JSON（最小改动法）
如果你已运行过 buffalo generate resource users name:string email:string，必须手动修正三处：
- 在
actions/users.go中，把所有c.Render(...)替换为c.JSON(200, data)或c.JSON(422, errors)，例如：c.Render(200, r.Auto(c, users))→c.JSON(200, users) - 在
app.go中注释掉或删除这三行：app.Use(session.Middleware)、app.Use(csrf.New())、app.Use(pop.Transaction) - 确认
app.Templates = nil已设置（否则r.Auto()仍会尝试找模板）
更稳妥的做法：用 --api 创建项目 + 手动加路由
从头开始更可控，避免后期清理陷阱：
- 运行
buffalo new myapi --api --skip-yarn，它会跳过 templates/、assets/、webpack 等前端相关目录 - 删掉
models/（除非你真要用 pop），改用database/sql或gorm直连 - 定义路由时不用
app.Resource，改用app.GET("/api/v1/users", UsersList)等显式方式，避免隐式中间件注入 - 在 handler 里直接用
json.NewEncoder(c.Response()).Encode(data)，绕过 Buffalo 的r.JSON和 plush 模板层，减少反射开销
真正该注意的点
Buffalo 的 CLI 在 2026 年已不可靠：buffalo install 失败、插件仓库归档、go install github.com/gobuffalo/cli/cmd/buffalo@latest 返回 404。即使硬装 v0.18.1，也得设 BUFFALO_PLUGIN_CHECK=false 才能启动。与其花时间绕过这些限制，不如三行 Gin 代码起步：
func main() {
r := gin.Default()
r.GET("/api/v1/users", func(c *gin.Context) { c.JSON(200, []map[string]string{{"id": "1"}}) })
r.Run(":3000")
}
它不加载模板、不校验 CSRF、不初始化 session、不自动开事务——你要什么，才加什么。这才是 API 开发的真实节奏。
