Go反射是解决类型未知问题的底层能力，用于序列化、ORM映射、配置加载等场景；reflect.TypeOf和reflect.ValueOf需配对使用，修改字段须满足可寻址和导出条件；性能差因绕过编译期检查，热路径应避免，初始化一次性使用可接受。
Go反射到底能干什么，哪些地方非用不可
Go反射不是“炫技工具”，而是解决「类型未知」问题的底层能力：当你拿到一个 interface{} 却不知道它背后是 struct{ Name string } 还是 []int，又或者需要把任意结构体自动转成 JSON 字段名、数据库列名、YAML 键时，反射就是唯一可行路径。
典型刚需场景包括：
- 序列化/反序列化库（如
json.Marshal底层就重度依赖反射） - ORM 框架字段映射（比如根据 struct tag 自动绑定 SQL 查询结果）
- 配置文件加载（把 YAML/TOML 解析后的 map 动态填充到任意 struct）
- 通用校验器或日志打点工具（遍历结构体所有导出字段并检查/记录）
但注意：这些都不是“必须手写反射”——绝大多数情况应优先使用已有成熟库；自己写反射，90% 是因为遇到了库不支持的定制逻辑。
reflect.TypeOf 和 reflect.ValueOf 是什么，为什么总要配对用
它们是反射的入口双胞胎：reflect.TypeOf 返回类型元信息（比如是不是指针、字段叫啥、有没有方法），reflect.ValueOf 返回值操作句柄（比如取值、设值、调用方法）。单独用其中一个，基本做不了完整事情。
常见误区：
- 传入普通变量（非指针）调用
reflect.ValueOf(x).Set(...)会 panic —— 因为值副本不可设置，必须传&x - 对 nil 接口调用
reflect.ValueOf(nil).Interface()会 panic，得先用IsValid()判空 -
reflect.TypeOf对接口变量返回的是「动态类型」，不是interface{}本身 —— 这正是你要的信息
示例：想安全获取任意值的字符串表示
func safeString(v interface{}) string {
rv := reflect.ValueOf(v)
if !rv.IsValid() {
return ""
}
return fmt.Sprintf("%v", rv.Interface())
}
为什么改字段值总失败？CanSet() 不是摆设
这是新手踩坑最密集的地方：反射修改值的前提不是“语法合法”，而是“内存可寻址 + 导出字段”。CanSet() 返回 false 的常见原因有三个：
- 传入的是值而非指针（
reflect.ValueOf(myStruct)→ 不可设；必须reflect.ValueOf(&myStruct).Elem()） - 字段未导出（首字母小写），Go 反射不允许修改非导出字段，连读都不让（
FieldByName返回零值） - 原始值本身是不可寻址的（比如字面量
reflect.ValueOf(42).CanSet()永远 false）
正确姿势示例（修改结构体字段）：
type User struct { Name string }
u := User{}
rv := reflect.ValueOf(&u).Elem() // 必须取地址再 Elem()
if nameField := rv.FieldByName("Name"); nameField.CanSet() {
nameField.SetString("Alice")
}
性能差在哪？什么时候该放弃反射
反射慢的核心在于：绕过了编译期类型检查和直接内存访问，每次调用都要查类型表、做合法性校验、解包接口、动态分发——实测简单字段访问比直接访问慢 10–100 倍，频繁调用极易成为瓶颈。
明确该放弃反射的信号：
- 代码在 HTTP handler、数据库查询循环、高频定时任务等热路径中
- 你只是想「判断类型然后分支处理」——用类型断言
v, ok := x.(MyType)更快更安全 - 字段数量固定、结构已知——硬编码访问永远比反射快，也更易调试
真正需要权衡的，是「一次初始化成本高，但后续零开销」的场景：比如 ORM 启动时扫描 struct tag 建立映射表，之后所有查询都走查表+直接赋值，这时反射只发生一次，是可以接受的。
最后提醒一句：Go 的反射没有运行时生成代码能力（不像 Java 的 Method.invoke 可缓存），每次 MethodByName 都要重新查找，务必提前缓存 reflect.Method 或 reflect.StructField。
