Go types.Interface.Empty 为什么不只看显式方法数量

types.Interface.Empty() 判断接口是否为空接口，也就是其类型集合是否涵盖所有类型。显式方法数量为零，只说明接口本层没有直接声明方法；嵌入方法、类型项和 comparable 限制都可能让它不再是空接口。把 NumExplicitMethods()==0 当成 Empty 的替代条件，会漏掉这些约束。

官方文档：https://pkg.go.dev/go/types#Interface.Empty

把空接口与没有显式方法分开

在给静态分析器选择条件时，我更倾向于先把问题写成完整中文：是在数声明，还是在判断允许哪些类型？前者对应方法数量，后者涉及接口的整体语义。这个区分比给一个布尔变量取名 isEmpty 更重要。

传统方法接口容易让人形成“没有方法就是空接口”的直觉。加入接口嵌入和泛型约束的语境后，这种捷径不够用了。本文解释现有语义，不虚构某次新提案或升级事件。

用四种声明比较旧判断与正确入口

下面在同一份源码中放入空接口、嵌入方法接口、底层类型约束和可比较约束。它们都没有直接声明方法，但并不都允许任意类型。

package main

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

func main() {
    // 对比无约束接口、嵌入方法和两种非方法限制。
    const source = `package sample
type Any interface{}
type HasName interface { Name() string }
type Embedded interface { HasName }
type IntegerLike interface { ~int }
type ComparableOnly interface { comparable }
`
    fset := token.NewFileSet()
    file, err := parser.ParseFile(fset, "sample.go", source, 0)
    if err != nil {
        panic(err)
    }
    conf := types.Config{}
    pkg, err := conf.Check("sample", fset, []*ast.File{file}, nil)
    if err != nil {
        panic(err)
    }

    // 使用固定名称顺序，避免依赖映射遍历顺序。
    for _, name := range []string{
        "Any", "Embedded", "IntegerLike", "ComparableOnly",
    } {
        obj := pkg.Scope().Lookup(name)
        if obj == nil {
            panic("没有找到类型：" + name)
        }
        iface, ok := obj.Type().Underlying().(*types.Interface)
        if !ok {
            panic(name + " 不是接口类型")
        }
        iface.Complete()
        fmt.Printf("%s explicit=%d methods=%d empty=%v\n",
            name, iface.NumExplicitMethods(),
            iface.NumMethods(), iface.Empty())
    }
}

按声明推导，Any 的 Empty 为 true；Embedded 虽然没有显式方法，却包含 Name；IntegerLike 和 ComparableOnly 即使方法总数也为零，仍有类型集合限制，所以 Empty 为 false。这些是示例语义的预期，未声称本地执行。

不要把 Empty 读成类型集合为空

这里有一个容易看反的命名点：Empty 指“空接口”，不是“没有任何类型能满足的空集合”。空接口没有限制，因此对应所有类型；一个限制互相冲突的约束可能没有满足者，但不会因此让 Empty 返回 true。

官方源码内部也区分这两个概念：表示所有类型的判断，与表示空类型集合的判断各有入口。因此工具的诊断文案最好使用“是否为空接口”，不要只写“集合是否为空”。我会把变量命名为 isEmptyInterface，减少后续维护者按集合术语误读的可能。

按分析目标选择判断入口

如果原分析器只服务普通接口展示，方法列表可能已满足需求；如果它还负责识别泛型约束、生成类型参数说明或判断是否存在限制，就不能继续把“方法数为零”作为通用条件。不要简单把显式方法数换成总方法数后就结束修复，因为类型项依然可能不体现在方法数量中。

在兼容处理里保留明确的使用边界

示例包含泛型约束语法，运行它需要支持该语法的 Go 工具链。约束接口能参与类型参数约束，不意味着所有这样的接口都可以当作普通变量类型使用。扫描器应先确认类型检查成功，再读取接口语义。

通过 NewInterfaceType 手工构造对象时，应等嵌入元素定义完成后调用 Complete。若输入来自有错误的源码，不要把缺失对象或不成立的类型断言静默解释成空接口，否则分析结果会把“没有读到资料”与“确实没有限制”混为一谈。

嵌入 any 还算空接口吗？如果没有其他限制，它仍对应所有类型，不能只看有没有嵌入项。没有方法且 IsMethodSet 为真呢？这与不含额外类型限制的情况相符，但直接需要空接口语义时使用 Empty 更清楚。需要判断某个具体类型是否满足约束怎么办？使用对应的类型满足关系 API，而不是仅比较方法数量。

源码参考：https://go.dev/src/go/types/typeset.go