buffalo g controller 用于生成控制器文件、路由注册及模板目录，但不自动绑定模型或DB操作；需手动创建模板、注入DB实例、处理错误类型，并注意大小写与路径匹配规则。
buffalo g controller 生成命令的基本用法
Buffalo 的 buffalo g controller 是生成控制器文件、路由注册和配套模板的快捷方式，不是纯代码模板填充工具——它会同时修改 actions/app.go 中的路由定义，并在 templates/ 下建目录结构。执行后需手动补全业务逻辑，框架不会自动绑定模型或数据库操作。
常见调用形式：
-
buffalo g controller users→ 生成actions/users.go、templates/users/目录，以及在app.Routes()中添加资源路由（GET /users等） -
buffalo g controller api/v1/posts→ 生成嵌套路径控制器，文件位于actions/api/v1/posts.go，路由前缀为/api/v1/posts -
buffalo g controller users index show create update destroy→ 显式指定动作，只生成对应方法体（不带实现），不生成未列出的动作
生成后必须检查的三个地方
自动生成的控制器只是骨架，很多关键连接点不会被自动处理，容易导致 404 或 panic：
-
actions/users.go中的每个 handler 默认返回c.Render(200, r.HTML("..."))，但对应模板路径可能不存在（如templates/users/index.html），需手动创建或改用r.JSON - 如果项目启用了 Pop ORM，
app.DB不会自动注入到 handler 参数里，需显式调用app.DB或从 context 获取（如c.Value("db").(*pop.Connection)，前提是已在 middleware 中设置） - 资源路由（RESTful）默认启用
OPTIONS和HEAD，但 Buffalo 不自动提供这些方法的 handler，若前端预检失败，要手动补OptionsHandler或禁用：app.Resource("/users", UsersResource{}).SkipOptions(true)
为什么 buffalo g controller 不生成模型关联代码
Buffalo 明确将“控制器”和“数据访问”职责分离：buffalo g controller 只管 HTTP 层，buffalo g model 才生成 Pop 模型。二者无自动绑定——即使你运行了 buffalo g model user 和 buffalo g controller users，UsersResource.Show 里也不会出现 user.Find() 这类代码。
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
这是设计使然，不是遗漏。你需要自己写：
- 在 handler 中调用
app.DB.Find(&u, params.Get("id"))或使用 Pop 的 Query 方法 - 注意字段 tag：Pop 要求模型字段有
json:和db:tag，否则Save()可能静默忽略字段 - 错误处理不能只靠
if err != nil，Pop 的Find在记录不存在时返回pop.ErrRecordNotFound，而其他错误（如 DB 连接失败）需单独判断
避免命名冲突与大小写陷阱
Buffalo 对控制器名的大小写敏感，且会直接影响 URL 路径和模板查找路径：
-
buffalo g controller AdminUsers→ 生成actions/admin_users.go，但路由注册为/admin_users（全小写下划线），不是/AdminUsers - 若已有
actions/users.go，再运行buffalo g controller Users会覆盖原文件（无提示），建议先git status确认 - 模板路径严格匹配控制器名：控制器名为
api/v1/posts，则模板必须放在templates/api/v1/posts/，多一个斜杠或少一个层级都会导致r.HTML找不到文件并 panic
真正麻烦的不是生成动作本身，而是生成后那几处没写进文档的隐式约定：模板路径推导规则、DB 实例获取方式、错误类型判别边界——这些地方不踩一次坑很难记住。
