http handler链天然不支持优先级，因其纯函数式嵌套结构无元数据描述执行顺序，仅靠包裹顺序决定执行流，无法动态调整；标准http.handler接口无priority字段，需通过结构体切片+排序显式管理中间件。
为什么 http.Handler 链天然不支持优先级？
Go 的标准 http.ServeMux 和常见中间件包装（比如 middleware1(middleware2(handler))）是纯函数式嵌套，执行顺序完全由包裹顺序决定，没有元数据描述“这个中间件该在第几层生效”。你没法在运行时动态插入、调整或跳过某一级——除非自己造一套调度逻辑。
常见错误现象：panic: http: multiple registrations for /path 或中间件重复执行/漏执行，往往是因为手动拼链时搞混了包裹方向（比如把日志中间件包在 auth 里面，结果 auth 失败后日志还没打出来）。
- 中间件越靠外，越早进入、越晚退出（类似洋葱模型最外层皮）
- 所有中间件共享同一个
http.ResponseWriter，一旦写入 header/body，后续中间件再写就可能 panic - 标准库无优先级字段，
http.Handler接口只定义一个ServeHTTP方法，无法携带权重或条件
用结构体 + 切片实现可排序中间件注册
核心思路：不依赖嵌套，改用显式列表管理中间件，按 Priority 字段排序后统一构建执行链。这样注册顺序无关，增删改都可控。
示例结构：
立即学习“go语言免费学习笔记（深入）”；
type Middleware struct {
Handler http.Handler
Priority int
Name string
}
<p>var middlewares []Middleware</p><p>func RegisterMW(h http.Handler, priority int, name string) {
middlewares = append(middlewares, Middleware{h, priority, name})
}</p><p>func BuildChain(final http.Handler) http.Handler {
sort.Slice(middlewares, func(i, j int) bool {
return middlewares[i].Priority < middlewares[j].Priority
})
chain := final
for i := len(middlewares) - 1; i >= 0; i-- {
chain = middlewares[i].Handler(chain)
}
return chain
}- 注意排序后倒序遍历：优先级数字小的先执行，所以要从高优先级（末尾）开始包起，才能保证低数字优先级在外层
- 不要在
RegisterMW里直接修改全局切片并发不安全；生产环境需加sync.RWMutex - 如果中间件需访问请求上下文（如
context.Context），确保它不依赖上层中间件注入的值（否则排序错乱会导致 nil panic）
优先级冲突时怎么选？别用数字硬编码
硬写 Priority: 10 或 Priority: 100 很快会失控。不同模块（auth、rate-limit、logging）各自定义优先级，很容易撞车或留不出插槽。
更稳妥的做法是定义常量锚点：
const (
PriorityEarly = -1000 // 如 TLS 检查、IP 白名单
PriorityAuth = -500 // JWT 解析、session 验证
PriorityRate = -100 // 限流
PriorityNormal = 0 // 默认业务中间件
PriorityLog = 900 // 日志、指标上报（必须在最后）
)- 用负数表示“前置”，正数表示“后置”，中间留出足够空隙供扩展
- 避免用
math.MaxInt这类极端值——某些中间件库内部会做优先级归一化，可能导致意外截断 - 如果两个中间件 Priority 相同，按注册顺序（非字典序）执行，这点要在文档里写明，不能假设稳定
性能和兼容性要注意什么？
每次请求都要走一遍中间件链，排序本身只在启动时发生，但链构建逻辑若放在 handler 内部（比如闭包里反复调用 BuildChain），会造成严重分配开销。
- 务必在服务启动完成、路由注册完毕后，**一次性**调用
BuildChain，返回最终http.Handler，而不是每次请求都重建 - 标准
http.ServeMux不支持中间件，必须用自定义http.Handler实现（如http.HandlerFunc包装） - 第三方框架（Gin、Echo）已有自己的中间件机制，强行混用易导致生命周期错乱（例如 Gin 的
c.Next()和你手写的链不兼容） - 调试时打印中间件顺序建议用
fmt.Printf("executing %s (priority=%d)\n", mw.Name, mw.Priority)，别依赖 IDE 断点——链式调用里断点容易跳飞
优先级不是万能解药。真正难的是定义清楚“谁该在谁之前”——比如 auth 和 CORS，到底是先验权再跨域，还是先加 header 再验权？这种语义依赖，代码排好序也救不了设计模糊。
