go反射不提供运行时类型安全检查，所有操作前必须手动验证：isvalid()、caninterface()、assignableto()或convertibleto()，否则调用set/convert等方法必panic。
Go 反射本身不提供运行时类型安全检查——它把类型是否兼容的判断权完全交给你，reflect.Value.Convert() 失败会 panic，reflect.Value.Set() 失败也会 panic，没有任何自动兜底。
反射操作前必须手动验证类型兼容性
反射不会替你做类型系统该做的事。比如你想把一个 reflect.Value 赋给另一个字段，不能直接 dst.Set(src) 就完事；必须先确认 src.Type() 和 dst.Type() 是否可赋值（src.Type().AssignableTo(dst.Type())），或是否可转换（src.Type().ConvertibleTo(dst.Type())）。
-
AssignableTo用于结构体字段赋值、接口实现判断等场景，要求底层类型一致或满足接口契约 -
ConvertibleTo用于数值类型转换（如int32→int64）、字符串/字节切片互转等，要求 Go 语言允许该转换 - 二者都返回
bool，不调用就无法知道结果；不检查就调用Set/Convert，一旦不兼容立刻 panic
IsValid() 和 CanInterface() 是安全调用的前提
很多 panic 来自对零值或不可导出字段的误操作。例如 reflect.ValueOf(struct{}{}).FieldByName("X") 返回的是无效值（!val.IsValid()），后续任何方法调用都会崩溃。
- 所有反射值操作前，先写
if !v.IsValid() { return }，这是最便宜的防御 - 想调用
v.Interface()必须先过v.CanInterface()，它比CanAddr()更严格，但Interface()明确要求它为true - 如果只是取底层值（比如想拿到
int数字），优先用v.Int()、v.String()等专用方法，它们内部已做有效性检查，且不依赖CanInterface()
JSON 解析后嵌套 interface{} 的断言陷阱
从 json.Unmarshal 得到的 map[string]interface{} 或 []interface{}，其内部元素仍是 interface{}，不是你期望的具体类型。常见错误是直接断言 v.(map[string]string) 或 v.([]map[string]interface{})。
- JSON 解析器只生成
map[string]interface{}、[]interface{}、基本类型（float64、string、bool、nil），不会生成map[string]string - 正确做法：先断言外层为
[]interface{}，再对每个元素用item.(map[string]interface{})，然后逐个字段再断言（如content := item["content"].(string)） - 若字段可能为空或类型不确定，务必用双值断言：
if s, ok := item["content"].(string); ok { ... }
反射缓存能避免重复开销，但不能绕过类型安全
高频反射（如 ORM 字段映射、日志 dump）中反复调用 reflect.TypeOf(x) 和 reflect.ValueOf(x) 开销显著。缓存 reflect.Type 和字段索引是标准做法，但它解决的是性能问题，不是类型安全问题。
- 缓存后仍需每次检查字段有效性：
field := v.Field(fieldIndex); if !field.IsValid() || !field.CanInterface() { continue } - 缓存的
reflect.Type不代表运行时值一定匹配——比如 struct 字段被设为nil，v.Field(i)仍会返回有效值，但v.Field(i).Interface()可能 panic（若该字段是不可导出指针） - 真正省不了的步骤：每次取值前的
IsValid()、每次导出前的CanInterface()、每次转换前的AssignableTo()或ConvertibleTo()
类型安全在反射里不是默认开启的开关，而是一道道你得亲手关上的门。漏掉任何一个检查，panic 就在下一行等着。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
