http.HandlerFunc是类型别名，实现了http.Handler接口，不能当普通函数直接调用；需提取核心逻辑为独立函数以复用，强行类型转换会破坏类型安全并引发panic。
为什么不能直接把 http.HandlerFunc 当普通函数用
http.HandlerFunc 是一个类型别名，底层是 func(http.ResponseWriter, *http.Request)，但它实现了 http.Handler 接口的 ServeHTTP 方法。这意味着它本身不是“可调用的普通函数”，而是一个带行为的函数值——你不能把它当参数传给期望纯函数的地方（比如某个需要 func(*http.Request) []byte 的工具函数），Go 会报类型不匹配。
怎么安全地提取并复用其逻辑
真正想复用的，其实是函数体里的业务逻辑，而不是包装后的 handler 行为。常见做法是把核心逻辑抽成独立函数，再由 handler 调用它：
- 把请求处理逻辑写成无副作用、纯输入输出的函数，例如
func handleLogin(r *http.Request) (int, []byte) - 在
http.HandlerFunc中调用它，并负责写响应：http.HandleFunc("/login", func(w http.ResponseWriter, r *http.Request) { status, body := handleLogin(r) w.WriteHeader(status) w.Write(body) }) - 这样
handleLogin就可以被单元测试、CLI 工具或 gRPC 方法复用，不再绑定 HTTP 层
强行转换会踩什么坑
有人试过用类型断言或强制转换，比如 (func(http.ResponseWriter, *http.Request))(myHandler)，但这只是绕过编译检查，实际运行时仍会 panic——因为 http.HandlerFunc 的底层结构包含方法表，不是裸函数指针。
- Go 不支持函数类型之间的运行时转换，
http.HandlerFunc和func(http.ResponseWriter, *http.Request)在反射层面是不同reflect.Kind - 即使编译通过（比如用
unsafe），也破坏类型安全，且在 Go 1.22+ 可能被禁止 - 真正需要“转”的场景，99% 是设计上混淆了 handler 和业务逻辑的边界
如果必须兼容旧 handler 签名怎么办
有些中间件或框架要求你提供 func(http.ResponseWriter, *http.Request) 类型的函数，而你手头只有 http.HandlerFunc 值。这时只需显式调用它：
-
myHandler本身是可调用的，类型即http.HandlerFunc，而该类型实现了func(http.ResponseWriter, *http.Request)的调用协议 - 所以你可以直接传：
someLib.RegisterHandler(myHandler) // 只要 someLib 接收的是 func(http.ResponseWriter, *http.Request)
- 但注意：不要写成
myHandler.ServeHTTP，那会丢失类型信息，变成func(http.ResponseWriter, *http.Request)的方法值，可能引发闭包捕获错误
真正难的从来不是语法转换，而是把路由层、协议层和领域逻辑拆干净。handler 是胶水，不是内脏。
