16.8 反射使用建议

本篇总结反射的适用场景与风险，帮助判断什么时候应该使用反射。

反射使用建议

概念说明

反射很强大，但也会带来成本。
它绕开了一部分编译期类型检查，让错误更容易延迟到运行时才出现。

写业务代码时，优先考虑普通类型、接口和泛型。
只有当逻辑确实需要“运行时查看未知类型”时，再考虑反射。

使用建议

框架、序列化、ORM、配置加载等通用逻辑更适合使用反射。
普通业务分支能用接口表达时，优先用接口。
需要复用同一套类型安全算法时，优先考虑泛型。
反射代码要加足够的 Kind、CanSet、IsValid 检查。
反射相关错误要尽量提前暴露，避免线上才 panic。

普通接口优先示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
package main

import "fmt"

type Validator interface {
	Validate() error
}

type User struct {
	Name string
}

func (user User) Validate() error {
	if user.Name == "" {
		return fmt.Errorf("name is empty")
	}
	return nil
}

func Check(value Validator) {
	if err := value.Validate(); err != nil { // 先走接口约束，不需要用反射
		fmt.Println(err)
		return
	}
	fmt.Println("ok")
}

func main() {
	Check(User{Name: "abin"})
}

输出结果：

1
ok

常见错误

反射还没学熟就大量用于业务代码，导致调试成本上升。
用反射替代清晰的接口设计，让调用关系变得不透明。
忽略反射 panic 风险，不做 IsValid、CanSet、Kind 等检查。
在性能敏感路径大量使用反射，却没有做基准测试验证影响。

章节

反射使用建议

概念说明

使用建议

普通接口优先示例

常见错误