reflect.TypeOf() 解决类型识别问题，返回只读的 reflect.Type 元数据；reflect.ValueOf() 解决值操作问题，返回可读写的 reflect.Value 封装体，需满足可寻址、导出、有效三条件才能修改。
reflect.TypeOf() 和 reflect.ValueOf() 各自解决什么问题
reflect.TypeOf() 只管“它是什么类型”，返回 reflect.Type；reflect.ValueOf() 管“它存了什么值”，返回 reflect.Value。二者输入都是 interface{}，但输出目标完全不同：一个纯描述性元数据，一个可操作的值封装体。
- 判断变量是否为
*os.File？用reflect.TypeOf(x) == reflect.TypeOf((*os.File)(nil)).Elem()—— 这里只比类型，不碰值 - 想把结构体某个字段设为
"modified"？必须用reflect.ValueOf(&s).Elem().FieldByName("Name").SetString("modified")—— 这里全程在Value上操作 -
Value对象可通过.Type()拿回类型，但Type对象永远拿不到值 —— 它们不是双向映射，而是单向依赖关系
Kind() 与 Name() 为什么不能混用
区分基础类别（Kind）和命名类型（Name）是避免误判的关键。比如 type MyInt int，它的 Kind() 是 int，而 Name() 是 "MyInt"；内建类型如 int、string 的 Name() 则为空字符串。
- 做类型分支判断时，一律用
Type.Kind()：只有它能稳定识别struct、ptr、slice等大类 - 检查是否为自定义命名类型（如用于标签解析或注册表匹配），才看
Type.Name() - 对指针调用
Type.Elem()前，务必先确认Kind() == reflect.Ptr，否则 panic
Value 修改失败的三大常见原因
想用 SetValue() 或 SetString() 却报错或静默失败？大概率踩中了这三个条件之一：
- 传入的是值而非指针：
reflect.ValueOf(x)得到的是不可寻址副本，必须用reflect.ValueOf(&x).Elem() - 字段未导出：
struct{ name string }中的name字段反射后CanSet()恒为false，哪怕你传了指针也没用 - 没校验有效性：
Value可能是无效的（如对 nil 接口调用ValueOf），操作前必须先v.IsValid()，否则直接 panic
什么时候该用 Type，什么时候非得用 Value
如果任务不涉及读/写具体数据，只分析结构或做类型路由，Type 就够了 —— 更轻、更安全、无副作用。一旦要取字段值、调方法、改内容，就必须上 Value，但代价是必须处理可寻址性、导出性、有效性三重约束。
立即学习“go语言免费学习笔记（深入）”；
- 实现 JSON tag 映射逻辑？
Type.Field(i).Tag+Value.Field(i)配合使用 - 仅校验参数是否实现了某接口？
reflect.TypeOf(x).Implements(someInterface)，不用碰Value - 性能敏感路径（如 HTTP 中间件高频调用）？优先用类型断言或泛型，反射留作 fallback 路径
最常被忽略的一点：反射对象本身不持有原始变量的引用，Value 是拷贝，Type 是只读视图；修改行为是否生效，最终取决于你传进去的是否是可寻址的原始内存地址 —— 这不是语法问题，是 Go 运行时模型的硬约束。
