http.Handle要求传入实现ServeHTTP方法的Handler接口类型，如结构体；http.HandleFunc是语法糖，将函数转为HandlerFunc类型后交由http.Handle处理，二者最终均注册到DefaultServeMux且行为一致。
http.Handle 要求传入实现了 ServeHTTP 方法的类型
你不能直接把一个普通函数传给 http.Handle，它第二个参数必须是满足 http.Handler 接口的值。这个接口只有一条契约：ServeHTTP(http.ResponseWriter, *http.Request) 方法。
所以常见写法是定义一个结构体，再为它实现该方法：
type MyHandler struct{ msg string }
func (h MyHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
w.Write([]byte(h.msg))
}
http.Handle("/api", MyHandler{msg: "from struct"})
- 结构体字段可携带状态（比如数据库连接、配置），适合需要复用或注入依赖的场景
- 注意接收者是值类型还是指针类型：若方法内要修改字段，得用指针接收者；但
http.Handle本身不关心这点，只要方法签名对就行 - 如果误传普通函数（如
http.Handle("/x", someFunc)），编译会报错：cannot use someFunc (type func(http.ResponseWriter, *http.Request)) as type http.Handler
http.HandleFunc 本质是 http.HandlerFunc 的语法糖
http.HandleFunc 看起来更轻量，但它底层做的事很明确：把你的函数转成 http.HandlerFunc 类型，再交给 http.Handle 处理。
http.HandlerFunc 不是函数调用，而是一个类型别名：
type HandlerFunc func(http.ResponseWriter, *http.Request)
func (f HandlerFunc) ServeHTTP(w http.ResponseWriter, r *http.Request) {
f(w, r) // 直接调用原函数
}
- 所以
http.HandleFunc("/ping", func(w http.ResponseWriter, r *http.Request) { ... })等价于：http.Handle("/ping", http.HandlerFunc(func(...) {...})) - 它适合无状态、一次性、逻辑简单的路由，比如健康检查、静态响应
- 闭包捕获变量时要注意生命周期 —— 若 handler 函数引用了外部局部变量（比如循环中的
i），所有路由可能共享同一个变量值，典型陷阱
Handler 和 HandlerFunc 在 ServeMux 中地位完全等价
无论你用 http.Handle 还是 http.HandleFunc，最终都注册到 DefaultServeMux 的同一张表里，匹配逻辑、执行流程、中间件兼容性完全一致。
-
DefaultServeMux内部只认http.Handler接口，http.HandlerFunc因为实现了ServeHTTP，所以能无缝接入 - 自定义中间件（如日志、鉴权）通常接收并返回
http.Handler，因此你可以统一包装两种来源的 handler：loggingMiddleware(myStructHandler)或loggingMiddleware(http.HandlerFunc(myFunc)) - 不要因为
HandlerFunc名字带 “Func” 就以为它性能更高 —— 它只是多一次函数类型转换，开销可忽略
什么时候该选哪个？看是否需要携带状态或复用逻辑
没有绝对优劣，关键在使用意图。
- 只需快速响应、无上下文依赖 → 直接用
http.HandleFunc，代码最短 - 需要持有一些初始化数据（如 DB 实例、配置对象、计数器）→ 定义结构体 +
http.Handle - 想把 handler 当作可测试单元单独导出 → 结构体方式更清晰，方便构造和 mock
- 想在 handler 内部做 panic 捕获或统一错误处理 → 两者都能做，但结构体方式更容易封装公共逻辑到方法中
最容易被忽略的一点是：http.HandlerFunc 是类型，不是函数；写 http.HandlerFunc(myHandler) 是类型转换，不是调用；漏掉这层理解，就容易在嵌套中间件或泛型约束中出错。
