fiber中间件执行顺序由app.use()注册顺序决定，先注册的先执行请求、后执行响应；路由级中间件在全局中间件之后、handler之前运行；c.next()是控制流开关，不调用则中断后续执行。
要让Fiber框架中多个中间件按预期顺序执行请求处理逻辑，必须严格遵循注册顺序和Next调用机制——注册在前的中间件先接收请求，而每个中间件内部是否调用c.Next()直接决定后续中间件能否运行。
Fiber中间件执行顺序由注册顺序决定
在Fiber中，app.Use()的调用顺序就是中间件的执行顺序。你写的第一行app.Use(mwA)，mwA就在最外层；第二行app.Use(mwB)，mwB就紧随其后。
这一步操作起来很简单，直接按你需要的前置优先级从上到下写Use语句就行。
注意：如果把鉴权中间件写在日志中间件之后，那么未通过鉴权的请求根本不会被记录——因为鉴权失败时调用了c.Abort()，日志中间件的响应阶段逻辑永远不会触发。
路由级中间件的执行位置
全局中间件（app.Use）→ 路由组中间件（v1.Use）→ 路由级中间件（app.Get("/x", mwC, handler)）→ 最终handler。
app.Get("/user", authMW, userHandler)中的authMW，只对/user这个GET请求生效，且一定在所有app.Use()之后、userHandler之前执行。
如果你在同一个路由上混用多种中间件注册方式，比如先app.Use(logMW)，再app.Get("/api", authMW, handler)，那logMW一定比authMW先拿到请求，authMW失败Abort()后logMW的响应逻辑也不会执行。
Next()的本质与调用时机
方法一：c.Next()是进入下一个中间件的唯一入口，它不是可选动作，而是控制流开关。
方法二：不调用c.Next()，当前中间件就终结整个链——后续所有中间件（包括同一路由定义里的其他中间件）全部跳过。这常用于权限拦截或静态响应返回场景。
方法三：c.Next()返回一个error，你可以用if err != nil { ... }捕获下游panic或Abort导致的中断，但【不要在c.Next()之后继续写业务逻辑】，除非你明确知道该中间件需在响应阶段补全操作（如记录耗时、修改响应头）。
嵌套结构如何影响执行流
第一步：理解Fiber底层仍是标准http.Handler包装链。当你写app.Use(mwA).Use(mwB)，等价于mwA(mwB(handler))。
第二步：请求进来时，执行路径是mwA → mwB → handler；响应返回时，执行路径是handler → mwB → mwA（后置逻辑倒序触发）。
第三步：如果mwB里调用了c.Abort()，则mwB的后续代码和handler都不会执行，同时mwA的响应阶段逻辑也不会运行——因为c.Next()没被完整调用到底层，外层包装无法收到返回信号。
这和Koa的“洋葱模型”形似但实现不同：Fiber不强制async/await，也不自动等待next返回，它依赖显式调用和错误传播机制。
