buffalo中间件执行顺序严格按app.use()或app.middleware.add()调用顺序决定：请求时正序执行、响应时逆序执行；默认中间件（recovery→logger→request_id）位于自定义中间件之后，需用append()/prepend()或重写handlers切确控制位置。
Buffalo 中间件注册顺序决定执行顺序
Buffalo 的中间件不是按“配置优先级”或“名称字典序”排的，而是严格按 app.Use() 或 app.Middleware.Add() 的调用顺序插入到全局中间件链中。你写在前面的，就先执行；写在后面的，后执行。这个顺序在 app.Routes() 之前就已固化，路由匹配之后不会重新排序。
-
app.Use(mw1)→app.Use(mw2)→app.Use(mw3)：请求时依次执行 mw1 → mw2 → mw3，响应时逆序：mw3 → mw2 → mw1 - 所有
app.Use()注册的中间件会插在 Buffalo 默认中间件（如 logger、recovery）之前；若想插在默认中间件之后，得用app.Middleware.Prepend()或app.Middleware.Append() - 如果用了
middleware.Automatic（比如通过buffalo.New()自动加载），它内部会把一组预设中间件按固定顺序塞进链头，你后续app.Use()的中间件反而会跑到它们前面——这常导致鉴权中间件在 logger 之前执行，日志里看不到原始请求头
如何把自定义中间件插到 recovery 之后、logger 之前
Buffalo 默认中间件栈顺序是：recovery → logger → request_id → ...。如果你希望某个中间件（比如 traceIDInjector）在 logger 记录前拿到 request ID，但又不能被 recovery 捕获 panic（即它不该参与 panic 恢复逻辑），就得绕过 app.Use()，改用 app.Middleware.Append() 显式追加。
- 错误写法：
app.Use(traceIDInjector)—— 它会插到 recovery 前面，panic 时 traceID 可能没打出来就被 recovery 吞了 - 正确写法：
app.Middleware.Append(traceIDInjector)—— 追加到整个链尾，确保 logger 已记录，且不干扰 recovery 行为 - 若需插在两个默认中间件之间（比如 logger 和 request_id 之间），Buffalo 不提供索引插入 API，只能手动重写整个中间件链：清空
app.Middleware.Handlers，再按需append()所有中间件（含默认的）
中间件顺序错乱的典型现象
最常被忽略的是 CORS 和 auth 中间件的位置。比如你把 middleware.CORS() 放在 auth 之后，OPTIONS 预检请求会直接 401，因为预检不带 token，但 auth 中间件已经提前拦截了。
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- OPTIONS 请求返回 401/403：CORS 中间件必须在 auth 之前，否则预检失败
- 日志里看不到 body 或 header：logger 中间件位置太靠后，上游中间件（如 body parser）已修改或 consume 了
http.Request.Body - session 写入失效：
session.Sessions()必须在middleware.PopTransaction之前，否则事务提交时 session store 还没 flush - 使用
buffalo-pop时，popmw.Transaction必须在所有业务 handler 之前，但必须在session.Sessions()之后，否则 session 数据无法跨事务持久化
调试中间件顺序的最快方法
别猜，直接打印当前中间件链。在 app.go 的 App() 函数末尾加一行：
for i, h := range app.Middleware.Handlers {
fmt.Printf("middleware[%d]: %v\n", i, reflect.TypeOf(h).Elem().Name())
}
启动 buffalo dev 就能看到完整顺序。注意：这个列表不含 PreWares（它们在请求进入中间件链前就执行了，比如 HostHeader 设置），也和 app.Resource() 里单独挂的中间件无关——后者只对那个 resource 生效，不进全局链。
真正麻烦的不是怎么调顺序，而是 Buffalo 的中间件模型根本不支持 per-route 顺序控制。一旦你拆服务，每个 service 都要自己维护一套中间件链，而 Buffalo 没提供 runtime 切换或条件注入机制——这时候该考虑换 Gin 或 Chi 了。
