go标准库不支持中间件动态排序，因其http.handler接口无priority等元数据，链式调用本质是编译期固定的函数嵌套mwa(mwb(mwc(handler)))，必须手动嵌套或用切片+排序显式管理。
Go 语言标准库不支持中间件执行顺序的动态配置，必须靠手动嵌套或显式切片排序实现；框架如 Gin、go-zero、GoFrame 提供了注册 API，但底层仍是函数包装，顺序由注册调用先后或结构体字段决定。
为什么 net/http 标准库没有中间件顺序配置能力
标准库 net/http 的 http.Handler 接口只定义 ServeHTTP 方法，不携带任何元数据（比如 Priority、Name 或 Enabled）。所有“链式调用”本质是函数嵌套：mwA(mwB(mwC(handler)))，编译期就固定了执行流。
- 无法在运行时插入、跳过或重排某一层——除非你自己实现调度器
- 写错包裹顺序（比如把
auth包在log里）会导致日志缺失、panic 捕获失效等静默故障 - 错误现象常见：
cannot use auth (type func(http.Handler) http.Handler) as type http.Handler，说明你漏掉了最终 handler 的包裹
Gin 框架中中间件顺序由 Use() 调用顺序决定
Gin 的 router.Use() 是语法糖，它把中间件按调用顺序追加到切片，再在路由匹配后依次包装。顺序即执行顺序，不可逆。
-
router.Use(logging(), auth(), rateLimit())→ 实际构造为logging(auth(rateLimit(handler))) - 如果想让日志记录完整耗时和 panic，
logging必须放在最外层；否则auth返回 401 后，日志根本不会触发 - 全局
Use()、分组Group().Use()、单路由GET("/x", middleware, handler)三者混合时，优先级：全局 - 别在中间件里用
go func() { ... }()直接调用c.Next()，Gin 的c不是 goroutine 安全的，会引发 context race 或 panic
用切片 + 结构体实现可排序中间件链（兼容标准库）
若需按优先级、名称或条件控制顺序，得放弃纯嵌套，改用显式管理：
type Middleware struct {
Handler http.Handler
Priority int
Name string
}
<p>var middlewares []Middleware</p><p>func AddMiddleware(h http.Handler, priority int, name string) {
middlewares = append(middlewares, Middleware{Handler: h, Priority: priority, Name: name})
}</p><p>func BuildChain(final http.Handler) http.Handler {
// 按 Priority 升序排列（数值越小越靠外）
sort.Slice(middlewares, func(i, j int) bool {
return middlewares[i].Priority = 0; i-- {
chain = middlewares[i].Handler(chain)
}
return chain
}
</p>
- 注册时不用关心先后：
AddMiddleware(auth, 10, "auth")、AddMiddleware(log, 5, "log")→log自动在外层 - 注意循环方向：从高 priority 到低 priority 逆序包裹，才能保证 Priority 小的先执行
- 所有中间件必须统一签名
func(http.Handler) http.Handler，否则chain = m.Handler(chain)编译失败 - 这个模式适合 CLI 工具、微服务网关等需要插件化加载中间件的场景
go-zero 和 GoFrame 的中间件注册差异
go-zero 使用 middleware 字段声明在 API 文件中，生成代码时硬编码进 handler 链；GoFrame 则通过 r.Middleware.Add() 注册，支持 Before()/After() 分阶段注入。
- go-zero 的
pingmiddleware.go中，handle方法签名是func(http.HandlerFunc) http.HandlerFunc，必须手动转成http.Handler才能参与标准链 - GoFrame 的
r.Middleware.Next()是阻塞调用，且r对象自带生命周期钩子（BeforeServe/AfterServe），比纯函数模型更易调试 - 二者都不支持运行时热更新中间件顺序；修改顺序必须重启服务或重新生成代码
- 跨框架迁移时，最易踩坑的是
ResponseWriter复用问题：多个中间件写同一w，谁先WriteHeader谁说了算，后续写会 panic
真正复杂的地方不在怎么写中间件，而在于如何确保它们共享的 http.ResponseWriter 不被提前消费，以及 panic 恢复中间件是否真的包住了整个链——这两点一旦出错，问题往往延迟暴露，日志里只有一行 http: response.WriteHeader on hijacked connection 或直接 500。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
