Go反射有三大不可逾越的法则：第一，所有反射操作始于interface{}，需传地址并检查IsValid；第二，Interface()还原需CanInterface()为真且类型匹配；第三，修改值必须满足CanSet()，即值可寻址且非未导出字段。
Go 反射不是“运行时随便改什么都可以”，它有明确的约束边界。三大法则不是教学口号，而是 reflect.TypeOf 和 reflect.ValueOf 行为的底层契约——违反任意一条，要么 panic，要么静默失效。
反射第一定律：interface{} → reflect.Type / reflect.Value
所有反射操作都始于一个接口值。reflect.TypeOf 和 reflect.ValueOf 的参数签名是 func(i interface{})，这意味着传入任何变量都会被隐式装箱为 interface{}，从而携带 (value, type) 二元信息。
常见错误现象：
- 直接对未取地址的 struct 字段调用
reflect.ValueOf，后续想修改却失败（违反第三定律） - 传入 nil 指针，
reflect.ValueOf返回零值Value，但.Kind()仍是ptr，容易误判
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 若需后续修改值，传入时必须是地址：
reflect.ValueOf(&x)，而不是reflect.ValueOf(x) - 检查
Value.IsValid()再继续操作，避免对 nil 接口或未导出字段做非法访问 -
Type.Kind()比Type.String()更可靠——前者返回reflect.Struct这类枚举，后者可能输出带包路径的字符串，不便于 switch 判断
反射第二定律：reflect.Value → interface{}
reflect.Value.Interface() 是唯一能将反射对象转回 Go 原生值的出口。但它只对“可表示为接口值”的 Value 有效，且类型必须匹配。
常见错误现象：
-
v := reflect.ValueOf(42); v.Interface().(string)直接 panic：类型断言失败 - 对不可寻址的
Value（如reflect.ValueOf(x)中的 x 是字面量或临时值）调用Interface()虽不 panic，但返回的 interface{} 无法再用于修改原变量
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 务必先确认
v.CanInterface()返回 true，再调用v.Interface() - 类型断言前用
v.Type().AssignableTo(targetType)或v.Kind() == reflect.String预检，比盲断更安全 - 不要依赖
Interface()来“绕过类型系统”——它只是还原，不是类型转换
反射第三定律：修改值必须满足 CanSet()
这是最常被忽略的一条。即使你拿到了 reflect.Value，也未必能改它指向的内存。核心条件有两个：值本身必须可寻址（addressable），且其 CanSet() 返回 true。
常见错误现象：
-
var x int = 1; v := reflect.ValueOf(x); v.SetInt(100)panic：“cannot set” - 从 map 中取值：
v := reflect.ValueOf(m)["key"]; v.SetInt(100)同样 panic，因为 map 元素不可寻址 - 结构体中未导出字段（小写开头）即使通过反射拿到
Field，CanSet()也返回 false
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 要修改变量，入口必须是
&x：v := reflect.ValueOf(&x).Elem()，然后检查v.CanSet() - 对 struct 字段修改前，先用
v.FieldByName("Name").CanSet()检查，而不是假设 public 字段一定可写 - map、slice、chan 等容器内元素不可直接设值，需先取指针再间接赋值（如
reflect.ValueOf(&slice).Elem().Index(i).Addr().Elem().SetInt(...)）
真正难的不是写出能跑的反射代码，而是在嵌套结构体 + 接口字段 + 泛型容器混用的场景下，准确判断每一层 Value 是否可寻址、是否可设、是否可转回 interface。这些判断没法靠直觉，只能靠反复验证 CanAddr()、CanSet()、CanInterface() 的返回值。漏掉一次，就是 runtime panic。
