buffalo.new()默认挂载session.middleware、pop.transaction、csrf.middleware、logger共4层中间件，即使未配置数据库或session也强制wrap请求，增加调用开销和context拷贝成本。
Buffalo 的中间件默认是串行 wrapper 链，不优化就会拖慢每个请求——尤其在 BFF 或 API 层这种对延迟敏感的场景。
buffalo.New() 启动时自动挂载了哪些中间件？
调用 buffalo.New() 会默认注入至少 4 层中间件：session.Middleware、pop.Transaction、csrf.Middleware、Logger。哪怕你没配数据库或 session，它们也照常 wrap 请求，每层都增加函数调用开销和 context 拷贝成本。
常见错误现象：curl -I http://localhost:3000/health 返回 200，但 pprof 显示 60% 时间花在 session.Middleware 的空检查上；app.JSON() 响应体被意外截断，其实是 render.Middleware 尝试渲染 HTML 模板失败导致 panic 后 fallback 到空响应。
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 必须显式禁用不用的中间件：删掉
app.Use(session.Middleware())和app.Use(pop.Transaction(app.DB)) - 禁用 CSRF：设
Options.DisableCSRF = true，否则所有 POST/PUT/DELETE 都走 token 校验逻辑 - 日志中间件可保留，但建议用
middleware.Logger{SkipPaths: []string{"/health"}}跳过探针路径
如何让中间件只在特定路由生效？
Buffalo 不支持 Gin 那种分组路由 + 中间件链式绑定，它的 app.Use() 是全局的。想实现“仅 /api/v1 下启用 auth 中间件”，得手动拆路由树：
- 用
app.Group("/api/v1")创建子路由组 - 在 group 内调用
group.Use(auth.Middleware)，而非app.Use() - 注意：group 的中间件只作用于该 group 下注册的 handler，不会污染根路由
- 别把
app.Resource()和 group 混用——Resource 自动生成的 CRUD 路由不继承 group 中间件，必须手写group.GET("/users", UsersHandler)
中间件里调用下游服务时 timeout 怎么透传？
Buffalo 的 buffalo.Context 默认用的是 request context，但它的生命周期和中间件 wrapper 绑定太紧，一旦进到 pop.Transaction 或 session.Middleware，原始 context 就被覆盖了。结果就是你设了 context.WithTimeout(ctx, 500*time.Millisecond)，下游 HTTP client 却永远等不到 cancel。
- 务必在中间件内重新构造 context：
ctx, cancel := context.WithTimeout(c.Request().Context(), 800*time.Millisecond) - 用完立刻
defer cancel()，否则 goroutine 泄漏 - 禁止直接用
c.Request().Context()传给http.Client.Do()，它可能已被上层中间件提前 cancel - 如果用了
pop查询，记得用pop.Connection.WithContext(ctx)替换默认连接
真正卡点不在写法，而在意识：Buffalo 的中间件不是“插拔式组件”，而是启动时就焊死在 handler 链上的 wrapper。优化效率的关键，是承认它不适合做轻量聚合层——该砍就砍，别试图“配置关闭”。
