handlerfunc 无法携带状态或配置，因其是无字段的函数类型别名，闭包不可靠且不支持依赖注入、中间件嵌套与统一预处理；结构体实现 http.handler 可封装依赖、复用逻辑并可控调度。
直接用 http.HandlerFunc 注册路由最省事，但想复用逻辑、传参或做预处理时，它就扛不住了——必须转成结构体实现 http.Handler 接口。
为什么 HandlerFunc 不能直接带状态或配置
http.HandlerFunc 是个类型别名：type HandlerFunc func(ResponseWriter, *Request)。它本身没字段、没方法，闭包能临时存点东西，但一跨请求就不可靠（goroutine 不保证复用），而且没法被其他组件注入依赖。
- 你不能给
HandlerFunc加一个timeout time.Duration字段 - 无法在多个 handler 间共享 logger 实例或 DB 连接池
- 中间件链（比如鉴权 → 日志 → 业务）没法自然嵌套，只能靠包装函数层层套，可读性差
结构体实现 Handler 是更可控的选择
定义一个结构体，把配置、依赖、上下文全塞进去，再实现 ServeHTTP 方法，就能干净地解耦和复用。
- 字段可以是
*sql.DB、log.Logger、config.Config等真实依赖 -
ServeHTTP内部可统一做context.WithTimeout、req.URL.Path解码、参数提取 - 支持组合：比如
type AuthHandler struct { Inner http.Handler; Auther Auther }，再在ServeHTTP里先校验再调h.Inner.ServeHTTP - 避免 panic：在
ServeHTTP开头加deferrecover，写http.Error(w, "internal error", http.StatusInternalServerError)，而不是让连接静默断开
HandlerFunc 和自定义 Handler 混用的常见陷阱
很多人图快，一半用 http.HandleFunc，一半用结构体 Handler，结果路由优先级混乱、中间件漏挂、日志不一致。
-
http.DefaultServeMux和你手写的Handler实例不是同一套调度逻辑，前者只做前缀/精确匹配，后者可能支持:id占位符——混用容易误判匹配顺序 - 如果用
http.ListenAndServe(":8080", nil)，实际走的是DefaultServeMux；但你传入自定义Handler实例时，整个调度都由你负责，http.HandleFunc注册的路由就失效了 - 路径参数提取后存在
req.Context()里，但HandlerFunc里拿不到——除非你手动req = req.WithContext(...)，而结构体Handler可以在ServeHTTP里统一做这件事
真正麻烦的不是写结构体，而是决定哪些逻辑该进结构体字段、哪些该抽成独立中间件函数。比如超时控制适合放结构体，而 CORS 头更适合做成 wrapper 函数套在 Handler 外层——边界模糊的地方，得看你的服务规模和迭代节奏。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
