go框架中中间件无优先级概念，执行顺序即use注册顺序，需手动构造带before/after依赖的middlewarespec切片，经拓扑排序后生成单链注入，避免直接多次调用app.use。
Go 框架里没有“中间件优先级”这个概念，Use 调用顺序就是执行顺序——这不是缺陷，是设计前提。想靠配置字段（如 Priority）动态排序，必须自己实现调度逻辑，不能依赖框架原生注册接口。
gin.Use() / echo.Use() / fiber.Use() 的顺序就是洋葱皮顺序
所有主流 Go Web 框架的 Use 方法都是追加到内部切片末尾，请求流严格按注册顺序进入、逆序退出：
-
app.Use(mwA)→app.Use(mwB)→app.GET("/x", h)⇒ 执行流为：mwA→mwB→h→mwB(返回) →mwA(返回) - 常见错误：把鉴权中间件
auth写在日志中间件log后面，导致 401 错误时没日志可查 - panic 场景：
mwA试图读取c.Get("user")，但mwB（负责 set）还没执行——说明顺序写反了 - 无法通过修改
mwA.Priority = 10让它自动插到mwB前面；框架根本不读这个字段
想支持 Priority 字段？绕过 app.Use，自己构造链
不要反复调用 app.Use，改用结构体切片 + 排序 + 链式包装：
- 定义中间件描述：
type MiddlewareSpec struct { Name string; Handler gin.HandlerFunc; Priority int; Before, After []string } - 启动时调用
topoSort(specs)做拓扑排序（注意检测环，比如A.After == "B"且B.After == "A"） - 用递归或闭包组装单个
gin.HandlerFunc，模拟c.Next()行为：前置逻辑 →next()→ 后置逻辑 - 最后只调一次
app.Use(BuildMiddlewareChain(specs))，把整条链塞进去
混用标准库 http.Handler 和框架中间件时顺序更易错
http 中间件永远在最外层，Gin/Echo/Fiber 中间件在内层——两套机制叠加时，顺序变成三层：
- 最外层：标准库
func(http.Handler) http.Handler（比如 CORS、超时控制） - 中层：框架
Use()注册的中间件（比如 JWT 解析、限流） - 最内层：路由 handler（比如
GET /user） - 典型陷阱：在 Gin 中间件里调
c.Abort()，但外层 http 中间件已写 header，会 panic：http: superfluous response.WriteHeader - 调试建议：每个中间件开头打日志，格式统一为
[layer=std] req start/[layer=gin] auth begin
真正麻烦的不是排序逻辑本身，而是中间件之间隐含的数据依赖——比如某个中间件必须在另一个之后写入 context 值，又必须在第三个之前读取。这种依赖关系一旦写进代码，就很难靠注释或文档维持一致性；最好用 Before/After 字段显式声明，并在启动时报错提示缺失依赖。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
