go反射中Value.interface()常panic，因需字段导出且Value可寻址；安全读取字段须用CanInterface()检查；Set*方法要求CanSet()为真；反射性能差10–100倍，禁用于高频路径。
Go反射中Value.Interface()为什么常panic？
直接对未导出字段或不可寻址的Value调用Interface()会触发panic，错误信息通常是reflect: call of reflect.Value.Interface on zero Value或reflect: call of reflect.Value.Interface on unexported field。根本原因是Go反射要求：必须通过导出字段访问、且Value本身需可寻址（即来自指针或地址取值）。
实操建议：
- 先用
v.CanInterface()判断是否安全调用Interface()，再执行； - 若源变量是普通值（非指针），需先用
reflect.ValueOf(&x).Elem()获取可寻址的Value； - 访问结构体字段前，务必检查
v.Field(i).CanInterface()，尤其在遍历匿名字段或嵌套结构时； - 不要对
nil指针做Elem()——会panic，应先用v.kind() == reflect.Ptr && !v.IsNil()防护。
如何安全读取结构体所有字段值（含私有字段）？
反射无法绕过Go的导出规则读取私有字段值——这是语言层面限制，不是API缺陷。所谓“读取私有字段”，实际只有两种合法路径：一是该结构体提供导出的getter方法；二是你持有该结构体的指针且它本身定义在当前包（即你写的就是这个Struct）。跨包私有字段永远不可反射读取。
实操建议：
- 用
reflect.typeof(x).NumField()和reflect.ValueOf(x).NumField()配合遍历； - 对每个字段，用
f := v.Field(i); if f.CanInterface() { fmt.Println(f.Interface()) }； - 若想统一处理（比如序列化），优先考虑实现
json.Marshaler或encoding/gob.GobEncoder接口，比硬撸反射更健壮； - 调试时可用
fmt.printf("%#v", v)快速查看Value内部状态，比手动Interface()更容错。
Value.Set*系列方法为何总报”cannot set”？
几乎所有Set*方法（如SetInt()、SetString()、Set()）都要求Value可设置（CanSet() == true），而它仅在Value由&x得来且x本身可寻址时为真。传入普通变量、常量、函数返回值都会导致CanSet()返回false。
实操建议：
- 修改变量值必须从指针开始：
v := reflect.ValueOf(&x).Elem()，然后才能v.SetInt(42)； - 对map/slice/chan等引用类型，
ValueOf(m)本身已是可寻址的（因底层是header指针），但SetMapIndex()等仍需目标key存在或提前SetLen()； - 向slice追加元素不能用
Set()，得用reflect.append()并接收返回值（slice是只读header）； - 调用
Set()传入另一个Value时，二者类型必须完全一致（包括包路径），int和int64不兼容。
反射性能差到什么程度？哪些场景绝对不该用？
反射调用函数比直接调用慢10–100倍；类型判断+字段遍历比硬编码慢5–20倍。这不是优化能解决的问题，而是动态类型解析、内存布局检查、安全校验带来的固有开销。
实操建议：
- 避免在高频路径（如http handler内层循环、定时器tick逻辑）中使用
reflect.ValueOf()或MethodByName()； - 配置解析、ORM映射、通用json转换这类“一次初始化、多次使用”的场景，可用反射构建缓存（如
map[reflect.Type]fieldInfo），后续走查表而非重复反射； - 生成代码（如
go:generate+stringer）比运行时反射更高效，gRPC、Protobuf默认就走这条路； - 当发现
runtime/debug.Stack()里频繁出现reflect.Value.Call或reflect.(*rtype).name，基本就是性能瓶颈点了。
反射不是语法糖，它是把编译期确定的事挪到运行时做。用之前先问自己：这个逻辑真的需要动态？有没有更静态、更明确的替代？