Buffalo全局中间件必须通过app.Use()注册，按调用顺序从上到下执行，函数签名须为buffalo.MiddlewareFunc，内部需调用c.Next()传递控制流；未调用则中断后续中间件与action；默认含CSRF、Session、DB事务等强耦合中间件，纯API场景应直接删除而非禁用。
Buffalo 的全局中间件必须在 app.Use() 中注册，且顺序决定执行顺序；中间件函数签名固定为 buffalo.MiddlewareFunc，不能直接传普通 http.Handler。
中间件注册位置和调用时机
所有全局中间件都写在 app.go 文件的 app.Use(...) 调用链中，位于 app = buffalo.New(buffalo.Options{...}) 之后、app.Serve() 之前。它会在每个请求进入路由匹配前被依次执行。
- 中间件按
app.Use()的调用顺序从上到下执行，越靠前的越先运行 - 如果某个中间件没调用
c.Next()，后续中间件和 action 都不会执行 -
app.Use()注册的是“全局”中间件，对所有路由生效；若需局部使用，应改用app.Group(...).Use(...)
自定义中间件函数怎么写
必须返回 buffalo.MiddlewareFunc 类型，内部通过 c.Next() 控制流程继续向下传递。不能直接返回 error 或调用 c.Render() 后就结束——除非你明确要拦截请求。
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
func MyLogger() buffalo.MiddlewareFunc {
return func(next buffalo.Handler) buffalo.Handler {
return func(c buffalo.Context) error {
log.Printf("request: %s %s", c.Request().Method, c.Request().URL.Path)
return next(c) // 必须调用，否则中断链
}
}
}
- 别写成
func(c buffalo.Context) error直接传给app.Use()，会编译报错 - 不要在中间件里调用
c.Response().WriteHeader()或任何可能提前写响应的操作，否则可能破坏后续中间件或 WebSocket 升级 - 若需访问原始
*http.Request或http.ResponseWriter，用c.Request()和c.Response().Writer，但注意 Buffalo 封装后它们不是原始类型
常见踩坑点：CSRF、Session、DB 连接池的隐式依赖
Buffalo 默认生成的 app.Use() 链里常含 csrf.New()、session.Middleware()、pop.Transaction(app.DB) 等。这些不是“可选装饰”，而是强耦合组件——哪怕你不显式用 session 或 DB，只要它们被 app.Use() 注册了，就会参与每次请求处理。
-
csrf.New()会尝试读写 cookie 并校验 token，纯 API 场景下没意义，还可能干扰 CORS 头 -
session.Middleware()会初始化 session store，即使你从不调c.Session()，也占用内存并增加锁竞争 -
pop.Transaction(...)会为每个请求分配 DB 连接并开启事务，API 服务若只做下游调用，这个连接池完全冗余 - 删掉不用的中间件比“禁用开关”更干净：直接注释或删除对应行，而不是留着再加条件判断
真正需要全局行为时（比如统一日志、请求 ID 注入、跨域头），中间件是合适入口；但别把它当成“兜底补丁”去掩盖路由设计或错误处理的缺陷。Buffalo 的中间件链一旦启动，就绕不开它的 Context 封装逻辑——这点和 Gin 的 gin.HandlerFunc 更轻量的模型有本质区别。
