Buffalo 框架不支持路由组或子路由器，中间件只能全局扁平注册且无作用域隔离；需通过函数封装中间件逻辑并由 handler 显式调用，如 RequireAdminAuth；复杂路由策略场景建议迁出 API 层至 Gin/Fiber。
Buffalo 框架本身不支持路由组（Group）或子路由器（Subrouter），所以“多路由组共享中间件”这个需求在 Buffalo 里没有原生写法——你不能像 Gin 那样写 r.Group("/v1/users").Use(jwtMiddleware())。强行模拟会破坏可维护性，容易踩坑。
Buffalo 的 middleware 是全局扁平注册的
Buffalo 的 app.Use() 和 app.UseAuthorizer() 注册的中间件会作用于所有路由，顺序固定、无作用域隔离。它没有 group.Use() 或 middleware.ForPaths() 这类 API。
- 所有中间件按注册顺序串成一条链，
app.Use(m1); app.Use(m2)→ 请求必经 m1 → m2 → handler - 想让
/admin/*走鉴权，/public/*不走？只能在中间件内部手动判断req.URL.Path前缀，再return或next.ServeHTTP() - 这种 if-else 分支越多，中间件越难复用、越难测试——比如你没法单独测“只对
/api/v2生效的 rate limit 中间件”
替代方案：用函数封装中间件逻辑，按需组合
与其硬套“路由组”概念，不如把中间件逻辑抽成纯函数，由 handler 显式调用。这样代码更可控，也符合 Buffalo 的设计惯性。
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 写一个
RequireAdminAuth(next buffalo.Handler) buffalo.Handler函数，内部做 path 判断 + token 解析 + 权限检查 - 在
actions/admin.go里，每个 handler 都显式包装：app.GET("/admin/users", RequireAdminAuth(UsersList)) - 如果多个 handler 共享同一套前置逻辑，可以再包一层：
func AdminRoutes(app *buffalo.App) { app.GET(..., RequireAdminAuth(...)); app.POST(..., RequireAdminAuth(...)) } - 注意：不要在
RequireAdminAuth里直接app.Use()，那又回到全局注册陷阱
避免掉进 middleware 顺序和 panic 的坑
Buffalo 的中间件链一旦 panic，整个请求就挂了，而且错误堆栈不指向你写的中间件——因为 app.Use() 注册的是包装器，不是原始函数。
- 调试时优先用
log.Printf("path: %s, method: %s", req.URL.Path, req.Method)打点，别依赖buffalo.Context.Log——它可能还没初始化 - 所有中间件必须显式调用
next.ServeHTTP(rw, req)，漏掉就会静默终止请求（无响应、无日志、无 error） - 涉及数据库或 context 注入的中间件（如
pop.Transaction），不能跨路径复用：/users 和 /orders 的 models 结构不同，强行共用会 panic
真正需要路由分组和策略隔离的场景，Buffalo 不是合适选择。它的定位是单体 Web 应用快速开发，不是微服务网关。如果项目已用 Buffalo 但开始拆服务，建议把 API 层逐步迁出，用 Gin 或 Fiber 做独立网关，Buffalo 留作管理后台或 SSR 页面服务——混用比硬改更可持续。
