go反射仅在需动态类型处理时使用，滥用会降低可读性、绕过编译检查、增加panic风险且性能差（call慢80倍）；优先用接口、泛型或代码生成替代；typeof轻量查元信息，valueof用于读写值但需传指针并检查有效性。
Go反射不是万能胶，也不是必须用的工具——它只在真正需要动态类型处理时才值得引入。滥用 reflect 会导致可读性下降、编译期检查失效、运行时 panic 风险上升，且性能开销明确（reflect.Value.Call 比直接调用慢约 80 倍）。是否要用，先问自己：有没有替代方案？比如接口抽象、泛型约束、代码生成？
什么时候该用 reflect.TypeOf 而不是 reflect.ValueOf
reflect.TypeOf 只读元信息，零拷贝、无运行时值依赖；reflect.ValueOf 会封装实际值，触发内存拷贝甚至堆分配。
- 做类型判断、字段遍历、结构体标签解析（如 JSON tag 映射）→ 优先用
reflect.TypeOf+Kind()+FieldByName - 需要读写字段值、调用方法、修改状态 → 才用
reflect.ValueOf，且注意传指针（否则SetXxx会 panic） - 对基础类型（
int,string）做类型检查时，reflect.TypeOf(x).Kind()比reflect.ValueOf(x).Kind()更轻量
结构体字段访问必须检查 CanInterface 和 CanAddr
反射获取字段后不能直接调用 Interface() 或 SetXxx()，否则常见 panic：reflect: call of reflect.Value.Interface on zero Value 或 reflect: call of reflect.Value.SetString on zero Value。
- 先确认
v := reflect.ValueOf(struct).FieldByName("Name")后，检查v.IsValid()和v.CanInterface() - 若字段是导出字段但结构体本身是值而非指针，
v.CanSet()为 false；必须传&struct才能修改 - 匿名字段嵌套时，
v.Elem()前务必确认v.Kind() == reflect.Ptr，否则 panic
interface{} 到具体类型的转换别硬断言
从 reflect.Value.Interface() 得到 interface{} 后，用类型断言（v.Interface().(string)）容易 panic。更稳妥的方式是结合 Kind() 做分支处理。
- 对已知可能类型（如配置解析），用
switch v.Kind()分支 +v.String()/v.Int()/v.Float()等安全取值方法 - 若必须转回原类型，先用
v.Type().Name()或v.Type().PkgPath()判断包路径，再做断言 - 切片或 map 字段不要反复用
v.Interface().([]T)，而应直接用v.Len()+v.Index(i)遍历，避免中间类型转换开销
最易被忽略的一点：反射对象不参与 GC 标记，reflect.Value 持有底层数据引用，若长期缓存 reflect.Value 实例（比如放在 map 里），可能导致本该释放的内存无法回收。需要动态操作时，尽量缩短其生命周期，别把它当“缓存型”对象用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
