两段代码，做同一件事——一个通用栈。

空接口版（interface{}）：

type Stack struct {
    items []interface{}
}

func (s *Stack) Push(item interface{}) {
    s.items = append(s.items, item)
}

func (s *Stack) Pop() interface{} {
    item := s.items[len(s.items)-1]
    s.items = s.items[:len(s.items)-1]
    return item
}

调用方的日常：

stack.Push(42)
stack.Push("oops") // 编译通过，运行时炸弹

val := stack.Pop().(int) // panic: interface conversion

编译器不管你往里塞了什么。类型对不对，跑起来才知道。

泛型版：

type Stack[T any] struct {
    items []T
}

func (s *Stack[T]) Push(item T) {
    s.items = append(s.items, item)
}

func (s *Stack[T]) Pop() (T, error) {
    var zero T
    if len(s.items) == 0 {
        return zero, fmt.Errorf("stack is empty")
    }
    item := s.items[len(s.items)-1]
    s.items = s.items[:len(s.items)-1]
    return item, nil
}

调用方：

stack := &Stack[int]{}
stack.Push(42)
// stack.Push("oops")  // 编译错误，走不到运行时
val, _ := stack.Pop()  // val 已知是 int

Benchmark 的结果更直接——泛型版快 2.9 倍，内存分配从每千次操作 755 次降到 12 次。

至少在这个场景，泛型完胜。但别急着在项目里搜索 reflect 然后全部删掉。

上一篇《Go 反射为什么"难用"？因为它本来就不想让你用》我们聊了反射为什么那么设计。这一篇回答一个更实际的工程问题：泛型发布两年了，哪些反射代码该改写，哪些动都不能动？

我选了 5 个最典型的反射使用场景，每个都写了两版代码、跑了 benchmark、给出迁移判定。不猜测，用数据说话。所有代码基于 Go 1.26.2，AMD EPYC 7K62 环境实测，go test -bench -benchmem -count=3 标准流程。

本文"反射"泛指依赖运行时类型信息的方案——包括 interface{} 的装箱/断言开销和 reflect 包的动态自省。场景 1 属于前者，场景 3-5 属于后者。

判断框架只有一条主线：你需要的类型信息，编译时能确定吗？ 能确定的部分归泛型，确定不了的部分归反射。五个场景从左到右覆盖了这条光谱的全部位置。

1. 类型安全容器：泛型完胜的主场

这是泛型最初被设计来解决的问题——参数化类型。Go 1.18 之前，你想写一个通用数据结构（栈、队列、堆、链表），只有一条路：用 interface{} 当万能类型，调用方自己负责断言。

痛点不只是运行时 panic 的风险。更隐蔽的问题是性能：每次你把一个值类型（int、float64、自定义 struct）塞进 interface{}，Go 运行时都要在堆上分配一个小盒子装它。取出来的时候，还要做一次类型断言验证。一千次 Push + Pop，就是一千次装箱 + 一千次断言。

泛型版本直接操作 []int，没有装箱，没有堆分配，没有运行时断言。编译器根据类型参数消除了运行时的装箱和断言——相同 GC shape 的类型共享代码，不需要为每个具体类型都生成一份。

看数据：

63 倍的分配差距是最值得关注的数字。更多分配意味着更频繁的 GC 暂停——如果你的服务对尾延迟敏感，这 63 倍的分配差距值得关注。

判定：✅ 完全可替代。 如果你的代码库里还有 interface{} 容器（通用栈、队列、集合、优先队列），现在就改。性能提升立竿见影，类型安全白送。零保留理由。

迁移成本也低得不值一提——改个类型声明、删掉所有类型断言，编译器会告诉你还漏了哪里。一个下午能迁完一个中型项目的所有容器代码。

2. JSON 序列化：分水岭在"类型是否编译时可知"

容器场景完胜。下一个问题：JSON 序列化——Go 社区最常见的反射使用场景之一——能被泛型接管吗？

答案是：看情况。关键问题只有一个——你在序列化的时候，类型信息编译时是否已知？

先看能赢的场景。如果你有一个明确的 struct（比如 User），编译时字段名、类型、顺序全部确定，你可以写一个零反射的泛型 marshaler：

type JSONMarshaler interface {
    MarshalFast() []byte
}

func MarshalGeneric[T JSONMarshaler](v T) []byte {
    return v.MarshalFast()
}

// User 实现 MarshalFast：手动拼接 JSON，零反射
func (u User) MarshalFast() []byte {
    buf := make([]byte, 0, 128)
    buf = append(buf, `{"id":`...)
    buf = strconv.AppendInt(buf, int64(u.ID), 10)
    buf = append(buf, `,"name":"`...)
    buf = appendEscaped(buf, u.Name)
    // ...
    return buf
}

核心思路：编译时已经知道 User 有哪些字段、什么类型、什么顺序，序列化逻辑可以在编码时"写死"——不需要在运行时一个字段一个字段地"摸"。

Benchmark：

每次调用省 300ns。单次调用你感觉不到差异，但在高频路径上这个差距会累积。如果你的服务每秒处理 10 万次 JSON 序列化（微服务间通信的常见量级），泛型方案每秒能帮你省出 30ms 的 CPU 时间。每年约 260 小时 CPU 时间——单服务影响有限，但在百实例集群中相当于省下 3 台机器的算力。

为什么差 3.2 倍？标准库 encoding/json 每次 Marshal 都要走这条反射链路：

reflect.TypeOf() → 遍历 NumField → 读 tag → 判断 Kind → reflect.Value 取值 → 类型转换

泛型版跳过了所有这些步骤——编码逻辑在编译时就已经"烧录"进去了。

注意：Go 团队的 encoding/json/v2（go.dev/issue/63397）在设计上已优化反射路径（类型信息缓存、减少分配）。当它正式进入标准库后，上述 3.2x 差距可能缩小——但"编译时已知→更快"的基本规律不变。

再看不能赢的场景。当你的函数签名长这样：

func HandleRequest(data interface{}) ([]byte, error) {
    return json.Marshal(data)  // data 是什么类型？编译时不知道
}

你没法写 MarshalGeneric[???](data)——那个 ??? 在编译时填不上。这不是"你不想用泛型"，是"泛型做不到"。类型参数必须在编译时解析，而 interface{} 的具体类型只有运行时才知道。

这正是 Go 标准库 encoding/json 至今没迁移到泛型的根因——json.Marshal(v interface{}) 这个签名向后兼容已有的亿级行调用代码，改不了也不该改。它天生就要处理运行时才确定的类型。

判定：⚠️ 部分可替代。 规则很简单——编译时类型已知→用泛型方案，可获 3x 提速；函数接收 interface{}→反射不可少。

实际工程建议：新写的内部代码尽量让类型在调用链中保持具体（别过早擦除为 interface{}），这样下游的序列化代码就能用泛型路径。老代码的公共 API 别强改——向后兼容比 3 倍性能重要。如果你在写新的 JSON 库或者内部编解码层，从第一天就用类型参数设计 API，性能红利直接落地。

3. 结构体验证：约束归泛型，元数据归反射

写过 validate:"required,min=3,max=50" 这种 struct tag 的人都知道，背后是 reflect 在逐字段扫描。Go 社区几乎所有验证库（go-playground/validator、ozzo-validation）底层都是 reflect.StructField + 字符串解析。

泛型能接管吗？

我实现了两版 validator 做对比。

反射版——通用引擎，任何 struct 丢进来就能验证：

func ValidateReflect(v interface{}) []ValidationError {
    val := reflect.ValueOf(v)
    typ := val.Type()
    for i := 0; i < val.NumField(); i++ {
        tag := typ.Field(i).Tag.Get("validate")
        rules := strings.Split(tag, ",")
        for _, rule := range rules {
            if err := applyRule(field, val.Field(i), rule); err != nil {
                errs = append(errs, *err)
            }
        }
    }
    return errs
}

泛型版——通过接口约束，每个类型自己实现验证逻辑：

type Validatable interface {
    Validate() []ValidationError
}

func ValidateGeneric[T Validatable](v T) []ValidationError {
    return v.Validate()
}

// 每个 struct 手写验证（零反射）
func (r CreateUserReq) Validate() []ValidationError {
    if r.Name == "" { ... }
    if len(r.Name) < 2 { ... }
    // ...
}

两版跑下来：

73 倍——五个场景中差距最大的。

这个 73 倍来自消除反射全链路——泛型在这里的作用是类型约束（确保实现了 Validate），性能提升来自手写逻辑本身，而非泛型机制。反射版每次调用要走完整条动态路径：reflect.ValueOf() 取值 → NumField() 遍历字段 → 对每个字段 Tag.Get("validate") 读 tag → strings.Split 解析规则字符串 → reflect.Value.Kind() 判断字段类型 → 逐规则执行验证。

泛型版（手写 Validate 方法）做的事：直接比较 r.Name == ""。没有反射，没有字符串解析，没有动态分派。编译器看到这个函数体足够小，直接内联了——连函数调用的开销都省了。

但 73 倍性能提升的代价是什么？每个 struct 都要手写一个 Validate() 方法。 反射版写一次引擎，一百个 struct 自动接入；泛型版写一百个 Validate() 方法。这不是"更好的方案"，这是不同的取舍。

更关键的是揭示了一条硬边界：struct tag 是运行时元数据。Go 的类型系统在编译时不暴露 tag 的具体内容。reflect.StructField.Tag 是唯一合法的读取方式。泛型的类型约束（type constraint）能约束"T 必须有某个方法"，但无法约束"T 的字段必须有某个 tag"。

工程中的最优解是分层：

• 外层：泛型约束确保类型"承诺了能验证自己"
• 内层：验证逻辑里可以用反射读 tag（或者手写，看你的取舍）

判定：⚠️ 部分可替代。 约束逻辑→泛型可以接管（73x 收益明显）；struct tag 读取→反射不可替代。在意性能的热路径上手写验证；其他地方继续用反射引擎省人力。

4. ORM 映射：泛型给了类型安全，性能快 0 倍

先说结论：泛型在 ORM 场景加速了 0 倍。struct tag + 动态赋值 = 反射跑不掉，泛型只是包了一层好看的壳。

反射版 ORM 的典型操作：

// 查询构建：反射读 struct tag 拼 SQL
func SelectReflect(table string, dest interface{}) string {
    t := reflect.TypeOf(dest).Elem()
    var cols []string
    for i := 0; i < t.NumField(); i++ {
        cols = append(cols, t.Field(i).Tag.Get("db"))
    }
    return "SELECT " + strings.Join(cols, ", ") + " FROM " + table
}

// 结果映射：反射动态给字段赋值
func ScanRow(dest interface{}, columns []string, values []interface{}) {
    v := reflect.ValueOf(dest).Elem()
    // 遍历列名 → 找到对应字段 → reflect.Value.Set()
}

泛型版——API 更好看，但底层呢？

table := NewTable[Article]("articles")
query := table.Select("author = ?", name)
// query 返回 *Query[Article]——编译时确定结果类型
// 但 BuildSQL() 内部仍需 reflect 读 tag
// ScanRow() 仍需 reflect.Value.Set() 动态赋值

Benchmark 不留情面：

几乎没有差距。 allocs/op 完全一样——性能瓶颈不在类型断言（那是场景 1 的问题），而在反射操作本身。泛型包了一层类型安全的壳，底下该用反射的一行没少。

核心洞察：泛型的性能提升来自"消除了反射的某个具体操作"，不是"加了泛型就快"。

为什么快 0 倍？看前三个场景的规律：

• 场景 1 消除了装箱分配 → 快 2.9 倍
• 场景 2 消除了字段遍历 → 快 3.2 倍
• 场景 3 消除了整个反射链路 → 快 73 倍
• 场景 4 什么也没消除（tag 还是要读，Set 还是要调）→ 快 0 倍

ORM 的核心工作是"把数据库的行映射到 Go struct 的字段"。这需要两件事：

1. 知道 struct 每个字段对应的列名 → 读 struct tag（db:"column_name"）→ 只能反射
2. 把值赋给对应字段 → reflect.Value.Set() → 只能反射

如果你在写新的数据访问层，值得用泛型包一层类型安全的 API（调用方不需要 .(*Article) 断言，编译器帮你确保 query.Scan() 返回的就是 []Article）。但别指望它能加速核心映射逻辑——性能优化的方向应该是减少反射次数（比如缓存类型信息），而不是"用泛型替代反射"。

判定：⚠️ 部分可替代。 泛型的价值在 API 层（类型安全、无需断言），不在性能层。核心映射逻辑里，反射没有替代方案。新写 ORM/数据层推荐：泛型 QueryBuilder + 反射映射引擎。

5. 插件系统：反射的不可替代领地

最后一个场景把问题推到极端：编译时完全不知道会遇到什么类型。

想象一个插件注册中心。第三方开发者写好插件，编译成 .so 文件（注意：Go plugin 包有平台限制且要求依赖版本一致，生产中更多见基于 gRPC 的插件通信——但动态分发的反射需求是相同的），运行时加载进主程序。主程序编译的时候，这些插件的代码根本不存在：

type PluginRegistry struct {
    plugins map[string]interface{}
}

// 运行时注册（编译时不知道 plugin 是什么类型）
func (r *PluginRegistry) Register(name string, plugin interface{}) {
    r.plugins[name] = plugin
}

// 动态调用（方法名运行时决定，参数类型运行时才知道）
func (r *PluginRegistry) Call(name, method string, args ...interface{}) {
    v := reflect.ValueOf(r.plugins[name])
    m := v.MethodByName(method)  // 运行时发现方法
    m.Call(reflectArgs)           // 运行时动态调用
}

试着用泛型改写：func Call[T any](plugin T, method string, args ...any) any——问题立刻暴露。T 在编译时必须确定。但你不知道 T 是什么。GreeterPlugin？MathPlugin？FuturePlugin？它们可能有完全不同的方法签名。你没法写一个泛型约束覆盖所有可能的插件。

接口方案适用于方法签名可预定义的场景（如 http.Handler）。但当方法签名在设计时不可枚举——不同插件有完全不同的方法名和参数——接口约束无法覆盖，反射是唯一出路。

反射在这个场景用了三个泛型永远做不到的能力：

1. reflect.TypeOf() —— 运行时获取一个值的类型信息
2. MethodByName() —— 运行时发现这个类型有哪些方法
3. reflect.Value.Call() —— 运行时构造参数并调用方法

性能代价当然存在——直接调用 0.3ns（编译器内联后的理论下限），reflect.Call 动态调用 1006ns，三千多倍差距——动态性的固有代价。你不会因为锁的开销放弃并发安全，同理反射的开销是运行时灵活性的合理票价。

你无法用编译时的机制解决运行时才有的信息。

如果你需要动态分发，这 1 微秒就是门票价格。

在实际系统中，插件调用频率通常不高（每秒几百到几千次），1 微秒的延迟完全可接受。反射在这里是唯一正确的选择。

同类场景还有很多——RPC 通用分发层、ORM hooks 系统、测试框架动态断言（testify/assert）、配置文件热加载。共同特征：类型信息在设计 API 的时候就不可能写死，因为使用者还没出现。

判定：❌ 不可替代。 当类型信息完全在运行时才可知（动态加载、插件注册、RPC 框架的通用分发层），反射是唯一选择。不要尝试迁移，迁移方向不存在。

决策速查表

五个场景跑完，规律已经浮现。把结果整理成一张你可以贴在显示器旁边的速查表：

*性能差距仅在泛型可接管的部分生效。混合场景中反射部分无性能变化。 †性能差距来自手写验证逻辑 vs 通用反射引擎，泛型仅提供类型约束。

核心判断维度：

• 容器：类型编译时完全可知，泛型直接接管
• JSON：已知类型走泛型路径，interface{} 入参走反射
• 验证：约束逻辑归泛型，struct tag 读取归反射
• ORM：API 层泛型提升体验，映射引擎离不开反射
• 插件：类型运行时才可知，反射是唯一选择

提醒：以上性能数据来自隔离的微基准测试。在典型 Web 服务中，反射开销占请求总延迟通常 <1%。决策框架的首要收益是类型安全和可维护性，性能提升是附带红利——别纯为 3 倍性能重构稳定运行的代码。

还有一条路：代码生成

本文聚焦泛型 vs 反射的二选一。但还有一条路径不在这条光谱上——代码生成（go generate）。easyjson、sqlc、wire 等工具在编译前生成类型特化代码，既不用反射也不用泛型约束。如果你的场景对性能极度敏感且类型结构稳定，代码生成值得单独评估。

泛型是编译时多态，反射是运行时自省。两者是互补关系。泛型发布两年后，反射从"什么都用它"的万能胶，退化为"只在特定手术台上用"的精准手术刀。应用面缩小了，但在那些手术台上——struct tag、动态分发、运行时类型发现——它不可替代。

下次你在 code review 里看到反射代码，问自己一个问题就够了：这里的类型信息，编译时能确定吗？能确定就开 PR 迁移泛型，不能确定就别动它。

你的项目里还有哪些反射代码拿不准该不该改？欢迎留言讨论。

附录：实验代码和原始数据

本文 5 组实验的完整 benchmark 代码已开源：

GitHub：zhiyulab-evidence/go-generics-vs-reflection

环境：Go 1.26.2 / AMD EPYC 7K62 / Linux / GOMAXPROCS=4。跑实验前自己 go build，二进制不入库。

原文发布于 止语Lab