buffalo中间件执行分全局（app.use）和路由级（app.get）两层，前者先于路由匹配执行，后者按洋葱模型“先注册后执行”；验证方式是用c.log().infof在入出口打带标识日志，避免fmt.println异步乱序。
中间件注册顺序和实际执行顺序不一致？
Buffalo 的中间件链执行顺序不是按 app.Use() 调用顺序线性叠加的，而是分两层：全局中间件（app.Use() 注册）和路由级中间件（app.GET("/path", middleware, handler)）。前者在进入路由匹配前执行，后者只对匹配到的路径生效，且**先注册的后执行**（类似洋葱模型外层）。如果你看到日志顺序反了，大概率是混淆了这两类注册方式。
怎么验证中间件是否真的按预期顺序执行？
最可靠的方式是让每个中间件在入口和出口都打日志，并带上唯一标识。别依赖 fmt.Println —— Buffalo 的日志默认异步，容易乱序。改用 c.Log().Infof，它绑定当前请求上下文，能保证时间戳和 trace ID 对齐。
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 在中间件函数开头加
c.Log().Infof("→ %s start", "MyMiddleware") - 在
next(c)调用后加c.Log().Infof("← %s end", "MyMiddleware") - 确保所有中间件都返回
error（哪怕只是nil），否则链会提前中断 - 避免在中间件里调用
c.Render()或c.Redirect()后还执行next(c)—— 这会导致 panic 或重复响应
常见陷阱：中间件被跳过或重复执行
以下情况会让中间件“消失”或“多跑一遍”：
-
app.ServeFiles()或静态文件路由没关掉：这些路径默认绕过大部分中间件，但如果你手动给它们加了中间件，就可能和全局链冲突 - 用了
app.Resource()：它内部会自动注入middleware.CSRF、middleware.PopTransaction等，和你手写的app.Use()叠加后顺序难预测 - 在
app.GET()里传了多个中间件，比如app.GET("/api/users", Auth, RateLimit, UsersList)，它们的执行顺序是 Auth → RateLimit → UsersList → RateLimit → Auth（出栈），但很多人只关注入栈部分 - 中间件里调用了
c.Response().WriteHeader()：一旦 header 写出，后续中间件的next(c)仍会执行，但无法再修改响应，容易误判为“没生效”
调试时别漏掉 Buffalo 的隐式中间件
Buffalo 在 app.New() 阶段会自动注入几个基础中间件（如 middleware.RequestID、middleware.Logger），它们不在你的代码里，但会影响实际链长度。想看清全貌，启动时加 -v 参数：buffalo dev -v，它会打印出完整中间件栈，包括来源文件和注册位置。重点关注那些来自 github.com/gobuffalo/buffalo/middleware 包的条目——它们优先级高，且不能用 app.Use() 覆盖，只能通过 app.Skip(middleware.Logger) 显式跳过。
