Buffalo控制器本质是buffalo.Handler函数，需显式声明buffalo.Context参数并返回error；它不自动解析请求参数或body，必须手动调用ParseForm()、json.Decode()等；响应须统一用c.Render()或c.Response()，不可混用。
Buffalo 的控制器（即路由 handler）本质是 buffalo.Handler 类型函数，不是传统 MVC 中的“类”，也不自动绑定参数或解析 body——它更接近 Go 原生 http.HandlerFunc，但带上下文增强。你必须手动调用解析方法，否则 c.Param()、c.Request().PostForm 等全为空。
handler 函数签名和上下文必须显式使用
Buffalo 的路由 handler 必须返回 error，且第一个参数固定为 buffalo.Context。这个 c 封装了 request/response、session、flash、log 等能力，但它不自动解析任何内容。
- 别写
func(c buffalo.Context) { ... }然后直接用c.Param("id")——如果没走app.GET("/users/{id}")这种带命名参数的路由，c.Param("id")一定为空 -
c.Request().URL.Query().Get("q")可读 URL 查询参数，但c.Request().PostForm需要先调c.Request().ParseForm()，否则 panic 或空值 - JSON 请求体必须手动
json.NewDecoder(c.Request().Body).Decode(&v)，Buffalo 不自动做body → struct绑定 - 别在 handler 开头就
defer c.Request().Body.Close()——buffalo.Context已管理生命周期，重复关会出错
返回响应不能混用 c.Render() 和 c.Response().Write()
Buffalo 提供两套响应路径：高层封装的 c.Render()（用于 HTML 模板、JSON、XML），和底层裸写的 c.Response()（用于文件流、自定义状态码、重定向）。二者互斥，混用会触发 http: multiple response.WriteHeader calls。
-
c.Render(200, r.JSON(user))自动设Content-Type: application/json并序列化，适合 API 返回 -
c.Render(200, r.String("ok"))返回纯文本，注意它仍带text/plain; charset=utf-8头 - 想返回文件流或自定义二进制内容，必须跳过
Render：c.Response().Header().Set("Content-Type", "application/pdf")→c.Response().WriteHeader(200)→c.Response().Write(data) - 一旦调了
c.Response().WriteHeader()或c.Response().Write()，再调c.Render()必 panic
中间件对 handler 执行顺序有强依赖
Buffalo 的中间件不是“装饰器”，而是按 app.Use() 注册顺序串行执行的函数链。handler 是否能拿到完整请求、是否被提前终止，全取决于中间件位置。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
middleware.ParameterParser必须在业务 handler 前注册，否则c.Param()永远为空；它默认只处理{id}这类路由参数，不解析 query 或 body -
middleware.PopTransaction会在 handler 执行前开启事务、结束后 rollback（测试时）或 commit（生产），但它只对 handler 内部调用pop.Model生效，不影响你手写的 raw SQL - 自定义中间件若调
c.Error(401)或c.Redirect()，会立即终止后续中间件和 handler，所以认证中间件必须放最前面 - 日志中间件
middleware.Logger若放在PopTransaction后，可能记录不到数据库错误——因为 panic 发生在 handler 内，而 logger 已结束
panic 和业务错误必须区分对待
Buffalo 把 panic 和 buffalo.Error 当作两类完全不同的控制流：前者是灾难性崩溃，后者是预期中的失败（如参数校验不通过）。handler 返回 buffalo.Error 会被框架转成对应 HTTP 状态码并渲染；而未被捕获的 panic 会导致连接中断或空响应。
- 别在 handler 里写
if err != nil { panic(err) }——这会让前端看到 500 但无日志，排查极难 - 正确做法是
if err != nil { return errors.WithStack(err) }或return c.Error(400, err)，让框架统一处理 - 全局 recover 中间件必须加判断：
if _, ok := r.(buffalo.Error); !ok { /* 记录 panic */ }，否则会把正常c.Error(404)也当崩溃处理 - 第三方库（如 Redis client）抛出的 panic，必须在 handler 内包一层
defer/recover，不能指望全局中间件兜底——因为有些 panic 发生在 goroutine 里，不在 HTTP 请求生命周期中
真正容易被忽略的是：Buffalo 的 buffalo.Context 是一次性的，它不跨 goroutine 传递。你在 handler 里启一个新 goroutine 并传入 c，那个 goroutine 里的 c.Render() 或 c.Session() 调用大概率失效——因为原请求可能早已结束，response writer 已关闭。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
