Go reflect.TypeFor 如何避免反射类型断言：TypeFor、AssignableTo 与注册表校验

做一个按类型注册处理器的小工具时，最容易绕远路的地方不是 map，而是“怎么拿到接口类型”。如果继续用 reflect.TypeOf((*Handler)(nil)).Elem()，代码能工作，却把空指针技巧和类型断言混在了一起。Go 1.22 提供的 reflect.TypeFor 可以直接取得编译期已知的类型，再用 AssignableTo 检查注册对象是否落在允许的接口边界内。

已知类型参数时优先用 reflect.TypeFor[T]()；注册表接收动态类型时，再用 AssignableTo 做明确校验。两者解决的是“取类型”和“验兼容”两个不同问题。

先拆开“取类型”和“验兼容”

反射注册表通常有两个动作。第一步是取得固定的目标接口，例如 Handler；第二步是判断用户传入的值是否可以赋给这个接口。过去常见的写法是对接口指针调用 reflect.TypeOf，再取 Elem。它并不表示要创建一个 Handler，只是借助 nil 指针找到接口的类型描述。

type Handler interface {
    Handle([]byte) error
}

var handlerType = reflect.TypeFor[Handler]()

func acceptsHandler(v any) bool {
    if v == nil {
        return false
    }
    return reflect.TypeOf(v).AssignableTo(handlerType)
}

这里的 handlerType 是目标，reflect.TypeOf(v) 是实际值的动态类型。不要把两个方向写反：我们要判断的是“实际类型能不能赋给 Handler”。

用一个小注册表把边界固定下来

注册动作最好在入口处完成，而不是等到真正处理请求时再断言。这样错误会带着传入类型返回，调用者也能决定是跳过、记录还是终止启动。

type Registry struct {
    items map[string]Handler
}

func NewRegistry() *Registry {
    return &Registry{items: make(map[string]Handler)}
}

func (r *Registry) Register(name string, value any) error {
    if name == "" {
        return errors.New("handler name is empty")
    }
    if value == nil {
        return errors.New("handler value is nil")
    }

    actual := reflect.TypeOf(value)
    if !actual.AssignableTo(handlerType) {
        return fmt.Errorf("%s cannot be assigned to Handler", actual)
    }
    r.items[name] = value.(Handler)
    return nil
}

类型断言出现在校验之后，所以它表达的是一个已经验证过的事实。若注册表允许覆盖同名项，还应在写入前决定覆盖策略；否则相同名称的第二次注册会悄悄替换第一次，问题会比反射本身更难查。

指针接收者是最容易误判的边界

接口实现集合取决于方法集。下面的 JSONHandler 只有指针类型实现了 Handler，值类型 JSONHandler 本身并不满足接口。AssignableTo 会把这个差异如实反映出来，不会因为名字相同就放行。

type JSONHandler struct{}

func (*JSONHandler) Handle(data []byte) error {
    return nil
}

func checkTypes() {
    pointerType := reflect.TypeFor[*JSONHandler]()
    valueType := reflect.TypeFor[JSONHandler]()
    fmt.Println(pointerType.AssignableTo(handlerType)) // true
    fmt.Println(valueType.AssignableTo(handlerType))   // false
}

如果业务想同时接受值和指针，就不能靠反射“猜”。要么为值类型也实现方法，要么在注册 API 中明确规定只接收指针，并在错误信息里给出实际类型。

用测试确认接口、别名和空值行为

这类代码不需要复杂基准，表格驱动测试更能说明契约。测试至少覆盖指针实现、错误的值类型、nil 和一个完全无关的类型。reflect.TypeFor 适合写在固定类型断言旁边，而动态输入仍然要先检查 reflect.TypeOf 是否为 nil。

func TestAcceptsHandler(t *testing.T) {
    cases := []struct {
        name string
        value any
        want bool
    }{
        {"pointer", &JSONHandler{}, true},
        {"value", JSONHandler{}, false},
        {"nil", nil, false},
        {"string", "json", false},
    }
    for _, tc := range cases {
        t.Run(tc.name, func(t *testing.T) {
            if got := acceptsHandler(tc.value); got != tc.want {
                t.Fatalf("acceptsHandler() = %v, want %v", got, tc.want)
            }
        })
    }
}

运行 go test ./... 后，重点看失败样例是否能指出“动态类型”和“目标接口”的差异。如果把 AssignableTo 换成 ConvertibleTo，测试也许会在简单类型上出现不同结果，但那已经改变了注册表的语义，不应为了让个别输入通过而替换。

相关问题

TypeFor 和 TypeOf 该怎么选？

目标类型在编译期已知时用 TypeFor[T]() 更直接；输入来自 any 或接口变量时，仍要用 TypeOf(value) 观察它的动态类型。

AssignableTo 能判断所有“可以转换”的类型吗？

不能。它判断赋值兼容；需要判断显式转换能力时才考虑 ConvertibleTo，两者不要混成一个注册条件。

为什么 reflect.TypeOf(nil) 要单独判断？

nil 接口没有动态类型，TypeOf(nil) 返回 nil，直接调用它的方法会 panic。入口处先拒绝 nil，错误路径会更清楚。

把反射注册表收口在入口

最后检查可以归结为三件事：固定类型用 TypeFor，动态值用 TypeOf，写入注册表前用 AssignableTo 验证。这样反射只负责描述类型，真正的业务选择仍由注册 API 的边界和测试来决定。