Go 泛型声明的类型参数列表怎样处理同组多个名字

做 Go 源码索引或泛型重构时，[A, B comparable] 很容易被误读成两个独立节点。实际上，go/ast 会把它表示成一个 *ast.Field：Field.Names 有两个标识符，Field.Type 只有一个共享约束。正确的处理方式是“先找到 TypeSpec.TypeParams，再遍历每个 Field 的全部 Names，并把同一个 Type 绑定给每个名称”。

同组多个名字不是只取 Names[0] 的理由。对 [A, B comparable]，索引结果至少应展开为 A → comparable 与 B → comparable 两条记录；约束表达式本身仍由 Field.Type 统一提供。

泛型参数列表的入口是 TypeSpec.TypeParams

解析文件后，顶层类型声明通常位于 *ast.GenDecl 的 Specs 中。拿到 *ast.TypeSpec 后，不要从 TypeSpec.Type 里猜方括号内容：它描述的是 struct{}、[]T 等被声明的类型；类型参数列表单独放在 TypeSpec.TypeParams，普通非泛型声明这里则是 nil。

一个 Field 里的 Names 必须全部展开

FieldList.List 的每项是一个字段组。对类型参数来说，字段组的名称数量和约束数量并不总是相等：同组写法会让多个名称共享同一个 Field.Type。因此，代码应先格式化一次约束，再遍历 field.Names，而不是把一项 Field 当成一个参数。

package main

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

// listTypeParams 只提取类型声明的类型参数，不处理函数形参。
func listTypeParams(src string) error {
	fset := token.NewFileSet()
	file, err := parser.ParseFile(fset, "sample.go", src, 0)
	if err != nil {
		return fmt.Errorf("解析源码失败: %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 {
						return true // 格式化失败时保留遍历，不伪造约束内容
					}
					constraint = buf.String()
				}
				for _, name := range field.Names {
					// 一个 Field 可能把同一约束绑定给多个名称。
					fmt.Printf("%s -> %s\\n", name.Name, constraint)
				}
			}
		}
		return true
	})
	return nil
}

这段逻辑的关键不是打印，而是数据模型：field.Names 决定要创建多少条参数记录，field.Type 决定这些记录共享什么约束。若后续要输出源码位置，可以在名称上调用 Pos()，再交给 token.FileSet.Position 转成文件、行和列。

共享约束和复合约束要分两层处理

对 [A, B comparable]，同一 Field 的两个 Names 都绑定到 comparable。对 [T any, S ~[]T]，每个 Field 仍然各自只有一个或一组名称，但 Field.Type 可能不再是简单的 *ast.Ident。保留 format.Node 生成的文本，可以先完成文档、索引和重构提示；需要理解约束集合时，再对 field.Type 做表达式分派，不能只看节点名称猜语义。

还要注意，声明参数和使用方的类型实参不是同一个入口。type Pair[A, B comparable] 访问的是 TypeSpec.TypeParams；而 Pair[int, string] 是一个 *ast.IndexListExpr，多个实参位于它的 Indices 切片。两者都出现方括号，但前者描述“声明了哪些参数”，后者描述“调用时传入了哪些实参”。

用三个边界避免提取结果失真

如果字段的 Names 为空，不要强行当作类型参数；ast.Field 也用于函数参数、结果、结构体字段和接口方法。稳定的提取器应先确认自己正在读取 TypeSpec.TypeParams.List，再应用“名称切片展开”的规则。

常见问题

为什么 [A, B comparable] 不是两个 Field？

因为语法上它们共享同一个约束，AST 用一个 Field 保存名称切片和约束表达式。需要两条业务记录时，在遍历 Names 时展开即可。

Field.Type 为空时还能生成参数名吗？

可以先保留名称，但应把约束标记为未提供或待分析，不要把空值替换成任意具体约束。参数列表的语法节点和后续类型检查是两件事。

IndexListExpr 能不能直接拿来读取声明参数？

不能。IndexListExpr 处理的是使用方的多类型实参；声明参数应从 TypeSpec.TypeParams 读取。

总结：处理 Go 泛型声明时，先从 TypeSpec.TypeParams 进入 FieldList.List，再对每个 Field 的 Names 全量展开，并让它们共享同一个 Field.Type。把声明参数和 IndexListExpr.Indices 分开，索引工具就不会把约束名和实例化实参混为一谈。