Go AST 怎样提取类型声明的类型参数及约束

做 Go 源码分析时，泛型类型声明不能只看 TypeSpec.Type。类型名后面的方括号列表单独存放在 TypeSpec.TypeParams 中：它是一个 *ast.FieldList，每个 *ast.Field 用 Names 保存参数名，用 Type 保存约束表达式。因此，提取逻辑可以概括为“找到 TypeSpec → 遍历 TypeParams.List → 展开 Names → 格式化 Type”。

对于 type Box[T any, S ~[]T]，应读取 TypeParams.List 中的两个字段：T 的约束是 any，S 的约束是 ~[]T。如果写成 [A, B comparable]，同一个 Field 的两个 Names 都要绑定到 comparable。

先把泛型类型声明定位到 TypeSpec

go/parser.ParseFile 产生的是整棵语法树，顶层类型声明通常表现为 *ast.GenDecl，其中 Tok 为 token.TYPE，具体类型项在 Specs 里。真正承载类型名和类型参数的节点是 *ast.TypeSpec。

普通声明的 TypeParams 为 nil，泛型声明才会有一个列表。这个判断很重要：不要从 spec.Type 的结构反推方括号内容，因为 spec.Type 表示的是结构体、切片、映射等被声明的底层类型。

用 Field.Names 和 Field.Type 还原参数约束

FieldList.List 的每一项对应一组语法上共享类型的参数。下面的写法只有一个 Field，但 Names 中有两个标识符：

type Pair[A, B any] struct {
	left  A
	right B
}

因此遍历时不能只取 field.Names[0]。应当先把字段的约束表达式格式化成文本，再为 Names 中的每个名称建立一条结果。没有名称的字段一般是嵌入字段，属于另一类 AST 语义，不要把它误当成类型参数。

package main

import (
	"bytes"
	"fmt"
	"go/ast"
	"go/format"
	"go/parser"
	"go/token"
)

// printTypeParams 只处理类型声明，不把被声明的底层类型当成约束。
func printTypeParams(src string) error {
	fset := token.NewFileSet()
	file, err := parser.ParseFile(fset, "sample.go", src, 0)
	if err != nil {
		return fmt.Errorf("解析 Go 源码失败: %w", err)
	}

	ast.Inspect(file, func(node ast.Node) bool {
		decl, ok := node.(*ast.GenDecl)
		if !ok || decl.Tok != token.TYPE {
			return true
		}
		for _, item := range decl.Specs {
			spec, ok := item.(*ast.TypeSpec)
			if !ok || spec.TypeParams == nil {
				continue // 普通 type 声明没有类型参数列表
			}

			for _, field := range spec.TypeParams.List {
				constraint := ""
				if field.Type != nil {
					var buf bytes.Buffer
					if err := format.Node(&buf, fset, field.Type); err != nil {
						fmt.Printf("%s: 约束格式化失败: %v\\n", spec.Name.Name, err)
						continue
					}
					constraint = buf.String()
				}
				for _, name := range field.Names {
					// 一个 Field 可能绑定多个名称，例如 [A, B comparable]。
					fmt.Printf("%s: %s -> %s\\n", spec.Name.Name, name.Name, constraint)
				}
			}
		}
		return true
	})
	return nil
}

这个实现保留了约束的语法形态，而不是把它提前解释成类型集合。对于源码索引、重构提示和文档生成，这样更合适，因为 ~[]T、interface{ ~int | ~string } 等写法仍然可以回显或继续按 AST 分析。

复合约束要继续看表达式节点

Field.Type 的静态类型是 ast.Expr，所以约束不是永远只有一个 *ast.Ident。例如 any 和 comparable 通常是标识符，~[]T 会包含更复杂的类型表达式，接口联合约束则会继续出现接口或二元表达式节点。提取名称时只需要先输出完整文本；如果下一步要做语义分析，再对 field.Type 做类型分派。

还要把类型声明与泛型实例化区分开。type Box[T any] 的参数列表在 TypeSpec.TypeParams；而 Box[int] 是使用方的索引表达式，多个类型实参可能对应 *ast.IndexListExpr 的 Indices。两者都出现方括号，但读取入口不同，混用会让索引工具把实参误报成约束。

输出结果时保留三个边界

如果工具还要给参数生成源码位置，可以使用 token.FileSet 把 name.Pos() 转成文件名、行号和列号；如果要判断约束的类型集合，则应交给 go/types 做类型检查，而不是仅凭 AST 节点名称猜结论。

常见问题

为什么 TypeSpec.Type 里找不到 T 和 any？

因为它们属于声明头部的类型参数列表，位置在 TypeSpec.TypeParams；TypeSpec.Type 只描述 struct{}、map[K]V 等被声明类型。

一个约束能不能对应多个参数？

可以。[A, B comparable] 会把 A、B 放在同一个 Field.Names 中，遍历名称切片即可展开成两条参数记录。

只用 AST 能判断约束是否满足吗？

不能把语法树遍历当成完整类型检查。AST 适合还原名称、源码形态和位置；是否满足约束、类型集合如何计算，应继续使用 go/types。

总结一下：提取 Go 类型声明的泛型信息时，入口是 TypeSpec.TypeParams，粒度是 FieldList.List，名称来自 Field.Names，约束来自 Field.Type。先按这个边界建模，再决定是否深入约束表达式，代码会比从底层类型节点反向猜测稳定得多。