handlerfunc 是将普通函数适配为 http.handler 接口的显式适配器，通过为类型定义 servehttp 方法实现接口，无隐式转换；它支持轻量路由与中间件链式组合，但需避免闭包导致的状态共享与内存泄漏问题。
http.HandlerFunc 不是语法糖，而是一个明确的适配器类型——它把普通函数“塞进”http.Handler 接口里，让函数能被标准库的路由系统直接使用。这是 Go 标准库里最轻量、最常用的适配器实践。
为什么必须用 HandlerFunc 包一层才能注册到 http.Handle？
http.Handle 只接受实现了 http.Handler 接口的值，而该接口要求有 ServeHTTP(http.ResponseWriter, *http.Request) 方法。普通函数（比如 func(w http.ResponseWriter, r *http.Request)）本身不带方法，不能直接满足接口。
HandlerFunc 类型定义为：type HandlerFunc func(http.ResponseWriter, *http.Request)，然后它显式实现了 ServeHTTP 方法：
func (f HandlerFunc) ServeHTTP(w http.ResponseWriter, r *http.Request) {
f(w, r)
}
这行代码就是全部逻辑：把接口调用转发给函数自身。没有额外开销，也没有隐式转换。
- 直接传函数给
http.HandleFunc是可行的，但那只是封装好的快捷入口，底层仍是http.Handle("/path", HandlerFunc(fn)) - 如果你手写
http.Handle("/path", fn)（fn 是普通函数），编译会报错：cannot use fn (type func(http.ResponseWriter, *http.Request)) as type http.Handler in argument to http.Handle - 结构体实现
http.Handler是另一种方式，但要写类型定义 + 方法，不如HandlerFunc一行搞定轻量路由
HandlerFunc 怎么链式组合中间件？
中间件本质是“包装一个 http.Handler，返回另一个 http.Handler”，而 HandlerFunc 让这种包装变得自然——你随时可以把它转回函数来调用，也可以用它构造新处理器。
典型日志中间件写法：
func logging(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
log.Printf("%s %s", r.Method, r.URL.Path)
next.ServeHTTP(w, r)
})
}
关键点在于：http.HandlerFunc(...) 构造了一个新处理器，内部闭包捕获了 next，并在调用时执行前置逻辑 + 委托原处理器。
- 不要写
return func(w, r) { ... }—— 这返回的是普通函数，类型不匹配，编译失败 - 中间件顺序很重要：越靠外的中间件越先执行（比如鉴权应在日志之后、业务之前）
- 多个中间件嵌套时，
logging(auth(handler))等价于auth包在logging里面，即先 auth 再 logging
自定义路由引擎里怎么安全复用 HandlerFunc？
自己写路由器时，别直接存 func 类型变量，统一用 http.HandlerFunc 类型声明字段或参数。这样既能兼容标准库，又保留扩展能力。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
例如定义路由结构体：
type Route struct {
method string
pattern string
handler http.HandlerFunc // ← 明确类型，不是 func(...)
}
这样做的好处：
- 可以直接调用
r.handler(w, r)，无需类型断言或二次转换 - 后续加中间件时，可直接用
http.HandlerFunc包装，和标准库行为一致 - 如果某天想升级为结构体处理器（比如需要带状态），只需让结构体实现
ServeHTTP，并仍可赋值给http.HandlerFunc字段（只要它满足接口）
注意：别在路由匹配后做 handler.(http.HandlerFunc) 断言——如果 handler 来源不确定（比如用户传入结构体），断言会 panic。统一用接口类型 http.Handler 存储更健壮，调用时统一走 ServeHTTP。
什么时候不该用 HandlerFunc？
当处理器需要维护状态、复用资源或响应不同请求逻辑时，HandlerFunc 的闭包容易导致内存泄漏或并发问题。
比如这个常见错误：
var counter int
http.HandleFunc("/count", func(w http.ResponseWriter, r *http.Request) {
counter++
fmt.Fprintf(w, "Count: %d", counter)
})
问题不止是竞态——counter 是全局变量，所有请求共享；更隐蔽的是，如果用闭包捕获局部变量并长期持有（比如缓存 map），GC 无法回收。
- 需要状态管理？用结构体字段 + 方法，而不是闭包捕获
- 要复用连接池、配置、数据库句柄？把这些作为结构体字段注入，而不是塞进闭包
- 想支持优雅关闭或初始化？结构体可以定义
Init()和Close()方法，函数做不到
适配器模式强大，但它的代价是“把函数变接口”的那一层薄薄的委托。一旦逻辑变重，就该换结构体——不是不能，而是不该硬撑。
