go中间件洋葱模型由函数调用栈天然决定，外层先处理请求、最后处理响应，内层handler居中执行；标准签名是func(http.handler) http.handler，必须显式调用如auth(handler)而非仅auth，漏调用或错序将破坏模型。
Go 的中间件洋葱模型不是抽象概念，它直接对应 next.ServeHTTP(w, r) 的调用时机和函数嵌套结构。外层中间件先拿到请求、最后拿到响应，内层（业务 handler）在最中心执行——这不是框架约定，而是函数调用栈天然决定的。
为什么中间件必须返回 http.Handler 或接收 http.HandlerFunc
因为 http.ListenAndServe 只接受 http.Handler 类型；而中间件本质是“包装器”，它必须能被传给下一个包装器或最终交给服务器。如果写成 func(http.Request, http.ResponseWriter) 就无法参与链式组合。
-
func(http.Handler) http.Handler是最标准签名，可直接用于http.Handle和任意嵌套 -
func(http.HandlerFunc) http.HandlerFunc更轻量，但必须显式转成http.Handler才能注册，例如http.Handle("/api", http.HandlerFunc(myMiddleware(finalHandler))) - 常见错误：
cannot use authMiddleware (type func(http.Handler) http.Handler) as type http.Handler—— 说明你漏掉了调用，比如写了authMiddleware而不是authMiddleware(handler)
logging(auth(handler)) 和 auth(logging(handler)) 执行顺序完全不同
洋葱模型是“后进先出”：最右边的 handler 是芯，每往左包一层，就加一瓣皮。阅读顺序建议从右往左：原始 handler → 最内层中间件 → 次内层 → … → 最外层。
-
logging(auth(handler))：先执行logging的前置逻辑（打日志），再进auth，再进handler；响应时先从handler返回，再经auth后置（无逻辑），最后回到logging后置（打耗时） -
auth(logging(handler))：未通过鉴权就直接拦截，logging根本不会执行；只有鉴权通过后才进入日志记录和业务逻辑 - 限流中间件一定要放在鉴权之后（否则恶意刷 token 会绕过限流），panic 恢复中间件必须在最外层（才能捕获所有内层 panic）
手动嵌套 vs 链式组合函数：哪个更可靠
手动嵌套如 cors(auth(logging(handler))) 最清晰、无隐藏行为、调试友好；链式组合函数（如 chain(m1, m2, m3)(handler)）看似简洁，但容易因循环方向写错导致顺序颠倒。
- 典型翻车点：循环从
i = 0到len-1，结果把m1包在最里层，完全违背预期 - 正确链式实现必须倒序遍历：
for i := len(mws)-1; i >= 0; i-- { h = mws[i](h) } - 中间件里漏掉
next.ServeHTTP(w, r)是静默失败——请求卡住、无响应、无错误日志，只表现为超时 - 提前终止时（如
http.Error），务必return，否则后续仍会执行next.ServeHTTP
洋葱模型的“层”不是配置项，而是函数调用栈的真实深度。每一层的前置逻辑在进入时执行，后置逻辑在返回时执行——这个对称性必须靠 next.ServeHTTP 的位置来保证，任何跳过、重复或错位都会打破模型。写中间件时，盯着这一行代码比看文档更重要。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
