go反射基于编译期类型信息，非动态类型系统；typeof只读类型，valueof封装值且需检查isvalid/canset；私有字段不可反射；多数panic源于状态误判，应优先用泛型等安全方案替代。
Go 的反射不是“运行时动态类型系统”，而是基于 interface{} 和编译期已知类型信息的有限能力扩展。它不能绕过类型安全，也不能在运行时凭空创建新类型——所有能反射出的信息，都必须在编译时存在。
reflect.TypeOf 和 reflect.ValueOf 的行为差异
这两个函数接收 interface{} 参数，但底层处理逻辑完全不同：
-
reflect.TypeOf(x)只读取x的静态类型信息（即x被传入时的 concrete type），不访问值内存；即使传入nil指针，也能返回正确类型 -
reflect.ValueOf(x)会封装值本身，若x是 nil 指针或未初始化的 interface{}，返回的Value的IsValid()为 false，后续调用Interface()或Set*会 panic - 对基本类型直接传值即可；但想修改变量，必须传指针并用
.Elem()解引用——否则CanSet()恒为 false
结构体字段反射必须满足导出条件
Go 反射无法读写非导出（小写开头）字段，这不是限制，而是语言封装原则的延伸：
-
FieldByName("name")对未导出字段返回无效Value（IsValid() == false） -
NumField()只统计导出字段数量；Field(i)索引只覆盖导出字段，不包含私有字段 - 结构体标签（如
`json:"name"`）可通过StructTag提取，但标签本身不改变字段可访问性 - 若需操作私有字段（如测试、调试），只能通过 unsafe（不推荐）或重构为导出字段+私有方法封装
反射常见 panic 场景与规避方式
多数 panic 来自误判 Value 状态，而非语法错误：
- 对不可设置的
Value调用SetInt()：先检查v.CanSet()，且确保原始值是以指针形式传入 - 对
nilinterface{} 调用ValueOf().Interface()：先用v.IsValid()判定，再用v.Kind() == reflect.Ptr && !v.IsNil()做二级防护 - 对非 struct 类型调用
FieldByName()：必须先确认v.Kind() == reflect.Struct - 用
Call()调用方法但参数类型/数量不匹配：应提前用m.Type.In(i)校验每个入参类型，而非依赖 runtime 错误
真正难的不是学会怎么调用 reflect.ValueOf，而是判断「此刻是否真的需要反射」——90% 的泛型替代场景（如容器、序列化）已有更安全的方案（any、~T、encoding/json 内置支持），只有当类型完全未知且必须统一处理时（如 ORM 字段映射、RPC 参数解包），才值得引入反射，并务必加运行时校验。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
