Go types.NewMethodSet 对指针和值为什么返回不同数量

我在给 Go 代码导航器补“类型有哪些方法”时，遇到过一个很容易误判的信号：同一个命名类型，传给 types.NewMethodSet 的 T 和 *T，返回的数量不一样。这个差异通常不是 API 漏了方法，而是 Go 的方法集本来就区分值类型和指针类型。

先记住结论：T 的方法集通常只包含接收者为 T 的方法；*T 的方法集可以包含接收者为 T 和 *T 的方法。接口类型、嵌入和指针层级会带来额外边界，所以分析器应把方法集和“某个表达式能否调用方法”分开判断。

官方地址：https://pkg.go.dev/go/types#NewMethodSet

先把返回数量不同归因到方法集规则

我第一次排这个问题时，直觉是“指针应该只是多一层地址，方法数量理应相同”。但 Go 规范把方法集定义在类型上：命名类型 T 和指针类型 *T 不是同一个类型，它们的候选方法集合也不相同。

假设有两个方法：Read 使用值接收者，Reset 使用指针接收者。此时 T 的方法集可以看到 Read，而 *T 可以看到 Read 和 Reset。因此，指针侧数量更多是正常边界，不应立即把问题归结为 go/types 的版本差异。

用一个最小类型区分 T 和 *T

下面的类型只用来说明接收者边界。代码中的输出是结构示意，重点是把两个 Type 分别传入 NewMethodSet，再观察每个 Selection 对应的声明对象。

package main

import (
    "fmt"
    "go/ast"
    "go/importer"
    "go/parser"
    "go/token"
    "go/types"
)

const source = `package sample
type Buffer struct{}
func (Buffer) Read() {}
func (*Buffer) Reset() {}`

func main() {
    // 先让 go/types 建立命名类型和方法声明，避免手工拼接 Type 对象。
    fset := token.NewFileSet()
    file, err := parser.ParseFile(fset, "sample.go", source, 0)
    if err != nil {
        panic(err) // 语法输入失败时没有可供枚举的方法集。
    }

    info := &types.Info{}
    pkg, err := (&types.Config{Importer: importer.Default()}).Check("sample", fset, []*ast.File{file}, info)
    if err != nil {
        panic(err) // 类型检查失败时不要继续读取不完整的包对象。
    }

    named := pkg.Scope().Lookup("Buffer").Type()
    valueSet := types.NewMethodSet(named)
    pointerSet := types.NewMethodSet(types.NewPointer(named))
    fmt.Println(valueSet.Len(), pointerSet.Len()) // 数量示意：指针侧通常更多。
}

这个例子里，值接收者方法会出现在两边，而指针接收者方法只会出现在指针侧。真正的工具代码还要处理接口、嵌入字段和错误包对象；不要把“通常更多”硬编码成“永远多一个”。

枚举 MethodSet 时应该看哪些字段

NewMethodSet 返回的是 *types.MethodSet。我在排查工具误报时，不只记录 Len()，还会逐项调用 At(i)，再从 Selection 取出声明对象和接收者类型。这样日志能说明“少了哪个方法”，而不是只留下两个数字。

func dumpMethodSet(label string, typ types.Type) {
    // MethodSet 代表某个静态类型的完整方法集合，不等同于一次调用表达式。
    set := types.NewMethodSet(typ)
    fmt.Println("method set:", label, "count:", set.Len())

    for i := 0; i 

At(i) 的结果是 Selection，它描述了方法选择关系。Obj() 更适合拿方法名和签名，Recv() 则帮助你区分当前方法集中的接收者视角。若工具只把名称扁平化成字符串，嵌入方法或不同接收者的同名问题会更难定位。

触发信号、处理和回滚边界

在代码导航、接口实现检查或重构工具里，可以把下面的信号当成排障入口：T 与 *T 数量不同、指针接收者突然消失、或者同名方法的声明位置看起来不一致。

回滚也要有边界：如果新版本只增加了方法集枚举日志，优先回滚“展示层”而不是改变类型归一化；如果为了让数量看起来一致而把 *T 解引用成 T，那会掩盖真实的指针接收者信息。我的做法是保留原始类型，再额外计算一个明确命名的业务视图。

复查时重点确认三项：输入类型字符串、方法声明对象、接收者类型。告警可以提示数量变化，但不能单凭数量判断接口是否实现；复盘记录则应写清楚是类型边界变化，还是工具把两个视角错误合并。

常见问题

为什么值类型有时也能调用指针接收者方法？

这是语言层面的可寻址调用规则，不等于 T 的静态方法集包含了所有 *T 方法。做类型分析时仍应按 NewMethodSet(T) 的结果处理。

把 *T 传给 NewMethodSet 就一定是 T 的超集吗？

对普通命名非接口类型，这是常见的直观结果；接口、嵌入、未命名类型和更复杂指针层级都可能改变你的观察方式。工具应保留具体 Selection，不要只比较数量。

什么时候应该改用 Implements？

如果问题是“某个类型是否实现某个接口”，优先使用 types.Implements 或相关接口检查 API。NewMethodSet 更适合解释方法集合、生成导航索引和展示接收者边界。