buffalo generate resource 生成含7个handler的actions文件、RESTful路由、HTML模板、models及迁移，但默认耦合session/CSRF/DB中间件和HTML渲染，API场景需手动剥离冗余逻辑才能可用。
buffalo generate 命令不是“一键生成可用代码”，而是生成带默认行为的骨架，必须手动剥离冗余逻辑才能用于 API 或定制场景。
buffalo g resource 生成了什么，又埋了哪些坑
运行 buffalo g resource users name:string email:string 后，它会生成：
-
actions/users.go：含Index、Show、New、Create、Edit、Update、Destroy七个 handler，全部默认调用c.Render() - RESTful 路由（如
GET /users），但路径前缀无法在资源定义中覆盖，app.Resource("/api/v1/users", &UsersResource{})会导致c.Param("id")失效 -
templates/users/下全套 HTML 模板，包括表单、flash 提示、布局嵌套——纯 JSON API 场景下完全无用 -
models/user.go和迁移文件，依赖pop/v6，但字段类型映射不支持uuid或jsonb等 PostgreSQL 特有类型，需手改 - 自动挂载
session.Middleware、csrf.Middleware、pop.Transaction，这些中间件在 API 请求中会直接报错或拦截响应
最典型错误是：你删了所有 .html 模板，却仍收到 template: "users/index.html" is undefined ——因为中间件链还在，c.Render() 仍被调用，且找不到模板。
buffalo g model 和 buffalo g migration 的参数差异
buffalo g model 生成结构体和迁移文件，但字段类型由字符串推断，不校验数据库兼容性：
-
name:string→ Go 中为string，DB 迁移为text（PostgreSQL）或varchar(255)（MySQL） -
age:int→ Go 中为int，迁移为integer；但若你实际想存smallint或带默认值，必须手动改models/user.go和迁移文件中的Column定义 -
active:bool→ 生成bool字段，但 SQLite 不原生支持布尔，迁移会写成boolean，运行时可能报cannot convert string to bool -
created_at:time不会被识别为时间戳字段，不会自动加timestamp约束或默认值，得手补sql:"default:current_timestamp"
buffalo g migration 只生成空迁移文件，不关联模型；若你先 g model 再 g migration，两个文件的字段定义不会同步，容易漏字段或类型不一致。
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
buffalo g task 怎么写才真正可运行
buffalo g task import-users 生成的是一个 stub，不能直接用。常见失败点：
- 函数签名必须是
func ImportUsers(c buffalo.Context) error，返回error；若写成func()或忽略c参数，buffalo task import-users会 panic -
models.DB在 CLI 环境下未初始化，需在函数开头显式调用models.NewDB()，否则db.Create()报nil pointer dereference - CSV 解析时没跳过 header 行：
records[1:]是硬编码，若文件无 header 会丢第一行数据；应先读一行判断是否含字段名 - 批量插入用
db.CreateInBatches()需确保用的是pop/v6的Transaction，而不是 GORM 的 API——Buffalo 默认不用 GORM，误抄示例会编译失败 - 任务里不能用
c.Session()或c.Flash()，CLI 上下文不提供 session 存储后端，调用即 panic
真正能跑的任务，核心就三行：db := models.NewDB()、defer db.Close()、db.CreateInBatches(data, 100)，其余都是防错包装。
为什么 buffalo g controller 不推荐用
buffalo g controller 生成的 handler 全部基于 c.Render() + HTML 模板，且默认绑定 app.Use(pop.Transaction)，对 API 场景完全反模式：
- 它不生成任何路由注册代码，你得自己去
app.go手写app.GET("/api/users", UsersHandler)，和g resource的自动化冲突 - 生成的
actions/users.go里没有UsersResource结构体，无法复用app.Resource()的统一中间件配置 - 若你后续想加验证逻辑，得在每个 handler 里重复写
if err := c.Bind(&u); err != nil { ... }，而Resource的Create方法已内置基础校验钩子 - 它生成的测试文件（
actions/users_test.go）用的是buffalo.TestRequest，但该工具只模拟 HTML 请求，无法测Content-Type: application/json场景
真实项目中，90% 的 controller 需求其实用 app.Resource() + 自定义 handler 替换更省事，g controller 只适合极简原型，且必须立刻重写所有 Render 调用为 JSON 或 XML。
生成命令最大的陷阱，是它把「结构」和「行为」耦合太紧：你拿到的不是干净接口，而是一整套默认假设（HTML 渲染、session、CSRF、事务）。删模板只是表面功夫，中间件链、handler 返回逻辑、测试桩才是真要动刀的地方。
