本文介绍如何通过解析 Go 源码 AST 并结合类型结构分析，无需完整类型检查即可判断用户指定的标识符（函数或变量）是否符合 http.Handler 的签名要求，适用于 CLI 工具中对自定义 HTTP 处理器的静态校验。
本文介绍如何通过解析 go 源码 ast 并结合类型结构分析，无需完整类型检查即可判断用户指定的标识符（函数或变量）是否符合 `http.handler` 的签名要求，适用于 cli 工具中对自定义 http 处理器的静态校验。
要判断一个动态指定的 Go 标识符（如 MyCustomHandler）是否可作为 http.Handler 使用，关键在于理解 http.Handler 的契约：它是一个接口，定义为：
type Handler interface {
ServeHTTP(ResponseWriter, *Request)
}
因此，任意类型只要实现了 ServeHTTP(http.ResponseWriter, *http.Request) 方法，即满足该接口。但在静态分析阶段（如 CLI 工具中），我们通常面对的是两种常见情形：
- 函数值直接赋给变量（如 var MyCustomHandler = func(w http.ResponseWriter, r *http.Request) {...}）；
- 函数声明本身（如 func MyCustomHandler(w http.ResponseWriter, r *http.Request)），该函数可被隐式转换为 http.HandlerFunc，进而实现 Handler。
由于仅使用 ast 包无法获取类型信息（ValueSpec.Type 常为 nil，尤其在类型推导场景），纯 AST 分析必须聚焦于“可判定结构”：即检查函数声明的参数签名是否严格匹配 ServeHTTP 方法签名。
以下是一个健壮、可复用的 AST 遍历函数，用于定位并验证目标函数是否具备 http.Handler 兼容签名：
func findHandlerFunc(pkg *ast.Package, name string) (*ast.FuncDecl, bool) {
for _, file := range pkg.Files {
for _, decl := range file.Decls {
fd, ok := decl.(*ast.FuncDecl)
if !ok || fd.Name.Name != name {
continue
}
// 检查是否为二参数函数：(http.ResponseWriter, *http.Request)
params := fd.Type.Params
if params == nil || len(params.List) != 2 {
continue
}
p1, p2 := params.List[0], params.List[1]
// 参数1：http.ResponseWriter
if !isHTTPResponseWriter(p1.Type) {
continue
}
// 参数2：*http.Request
if !isPtrHTTPRequest(p2.Type) {
continue
}
return fd, true
}
}
return nil, false
}
// isHTTPResponseWriter 检查类型是否为 http.ResponseWriter
func isHTTPResponseWriter(expr ast.Expr) bool {
sel, ok := expr.(*ast.SelectorExpr)
if !ok {
return false
}
ident, ok := sel.X.(*ast.Ident)
if !ok || ident.Name != "http" || sel.Sel.Name != "ResponseWriter" {
return false
}
return true
}
// isPtrHTTPRequest 检查类型是否为 *http.Request
func isPtrHTTPRequest(expr ast.Expr) bool {
star, ok := expr.(*ast.StarExpr)
if !ok {
return false
}
sel, ok := star.X.(*ast.SelectorExpr)
if !ok {
return false
}
ident, ok := sel.X.(*ast.Ident)
if !ok || ident.Name != "http" || sel.Sel.Name != "Request" {
return false
}
return true
}
✅ 注意：此方法仅验证函数签名，不保证实际实现逻辑正确，但已足够支撑 http.Handler 的静态兼容性断言（因 Go 的接口实现是隐式的、基于签名匹配的）。
若需支持更复杂场景（如变量声明 var h http.Handler = MyCustomHandler 或嵌套类型别名），则必须升级到 go/types 包进行完整类型检查——这需要构建 Config、Importer 并执行 Check，开销显著增加，但精度更高。示例简略流程如下：
conf := &types.Config{
Importer: importer.ForCompiler(token.NewFileSet(), "source", nil),
}
info := &types.Info{Types: make(map[ast.Expr]types.TypeAndValue)}
_, err := conf.Check("", fset, []*ast.File{file}, info)
// 然后通过 info.Types[ident].Type() 获取实际类型，并用 types.Implements() 判断是否实现 http.Handler
总结：对于命令行工具等轻量级静态分析需求，优先采用 AST 结构匹配（如上文函数签名检测），简洁高效；仅当需处理类型别名、接口嵌套、跨包别名或泛型等高级特性时，才应引入 go/types 进行全量类型检查。二者并非互斥，而是分层演进的关系——从“结构可信”走向“语义可信”。
