http.HandlerFunc 能直接当 http.Handler 用，因为它是函数类型别名且隐式实现了 ServeHTTP 方法，将调用转发给自身；普通函数需经 http.HandlerFunc 包装才符合接口要求。
为什么 http.HandlerFunc 能直接当 http.Handler 用？
因为 http.HandlerFunc 是一个类型别名，底层是函数类型，并且它实现了 http.Handler 接口的 ServeHTTP 方法。Go 的接口实现是隐式的，只要类型有对应签名的方法，就自动满足接口 —— 而 http.HandlerFunc.ServeHTTP 就是把调用转发给它自己这个函数。
所以你写 func(w http.ResponseWriter, r *http.Request) { ... }，再用 http.HandlerFunc(...) 包一层，就得到了一个合法的 http.Handler 实例。
-
http.HandlerFunc本身不是函数，而是一个可调用的类型（类似“带方法的函数”） - 它不改变原函数逻辑，只是补全接口契约
- 不能直接把裸函数赋值给
http.Handler变量，会报错：cannot use … (type func(http.ResponseWriter, *http.Request)) as type http.Handler
怎么把普通函数转成 http.Handler？三步到位
假设你有一个处理逻辑封装好的函数：
func myHandler(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(200)
w.Write([]byte("hello"))
}
把它变成 http.Handler，只需一行包装：
立即学习“go语言免费学习笔记（深入）”；
Golang Samber Hot
下载
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
handler := http.HandlerFunc(myHandler)
之后就能传给 http.ListenAndServe、mux.Handle 或中间件链：
http.Handle("/path", http.HandlerFunc(myHandler))-
router.HandleFunc("/api", myHandler).HandlerFunc(http.HandlerFunc(myHandler))（注意：后者是冗余写法，HandleFunc内部已做转换） - 中间件如
loggingMiddleware(http.HandlerFunc(myHandler))，前提是中间件接收http.Handler
常见错误：函数签名不对或漏包一层
最常踩的坑是函数签名和 http.HandlerFunc 不匹配，或者误以为“写了函数就等于 handler”。
- 参数顺序反了：
func(r *http.Request, w http.ResponseWriter)→ 编译失败，必须是w在前、r在后 - 少一个参数：
func(w http.ResponseWriter)→ 类型不匹配，http.HandlerFunc要求两个参数 - 多一个参数：
func(w http.ResponseWriter, r *http.Request, extra string)→ 无法转成http.HandlerFunc，得先闭包或重构 - 忘记包一层：
http.Handle("/x", myHandler)→ 编译报错，Go 不允许函数值直接赋给接口变量（除非该函数类型已定义为接口实现者）
什么时候不该用 http.HandlerFunc？
如果你的 handler 需要携带状态（比如数据库连接、配置），或需要多次复用不同参数的变体，硬塞进裸函数里会难维护。这时候更适合定义结构体并实现 ServeHTTP 方法：
type UserHandler struct {
db *sql.DB
}
func (h *UserHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
// 使用 h.db
}
这种写法比反复闭包更清晰，也避免逃逸和内存分配开销。
另外，如果函数本身已经返回 http.Handler（比如某些库的工厂函数），就别多套一层 http.HandlerFunc —— 容易嵌套过深、调试困难，也违背接口本意。
