必须用 reflect 的场景是编写通用代码时绕不开类型未知问题，如 ORM、序列化库、配置绑定、RPC 框架等，需动态处理任意结构体的字段映射、标签读取、值填充、方法调用及校验日志等。
什么时候必须用 reflect？不是“能用”，而是“绕不开”
Go 是静态强类型语言，编译期就锁死类型；而当你写的是通用代码（比如 ORM、序列化库、配置绑定、RPC 框架），根本不知道调用方传进来的是 User 还是 Order，更别说字段名和标签内容——这时候不用 reflect 就只能硬编码、重复造轮子、或者直接放弃通用性。
- 需要根据结构体
db或json标签生成 SQL / JSON 字段映射 - 要实现类似
json.Unmarshal那种“传任意指针，自动填字段”的能力 - 框架层需统一处理不同业务结构体的校验、日志打印、审计埋点
- 动态调用方法（如插件系统、命令路由），方法名来自配置或用户输入
注意：这些场景下，interface{} 只是入口，真正干活靠的是 reflect.TypeOf 和 reflect.ValueOf 拆解出元信息。
reflect.Value.CanSet() 为什么总返回 false？
这是最常踩的坑：你以为拿到了字段，一调 SetString 就 panic，报 reflect: reflect.Value.SetString using unaddressable value。根本原因只有一个：你没传指针，或传了但没 .Elem()。
- 对变量取反射值，必须用
reflect.ValueOf(&x).Elem()，而不是reflect.ValueOf(x) - 结构体字段本身不可导出（小写首字母）→
FieldByName返回零值 →CanSet()必为 false - 即使字段导出，若原始值是拷贝（如
reflect.ValueOf(u)而非reflect.ValueOf(&u)），字段仍是不可寻址的 - 调用
CanSet()是强制步骤，不能跳过；它比IsValid()更严格，检查的是“能否写入内存”
示例中常见错误写法：v := reflect.ValueOf(u); v.FieldByName("Name").SetString("x") —— 这里 v 是结构体副本，字段不可设。
立即学习“go语言免费学习笔记（深入）”；
读标签、遍历字段、调方法，三步操作的关键差异
看似都是“反射结构体”，但每一步的 API 路径和权限要求完全不同：
-
读标签：用
reflect.TypeOf(u).Field(i).Tag.Get("json")，只依赖类型信息，无需值；FieldByName也可，但要注意字段名大小写 -
遍历字段值：必须用
reflect.ValueOf(&u).Elem()得到可寻址的 struct 值，再循环v.Field(i).Interface()；若字段是 slice/map，还得用v.Len()、v.MapKeys()等专用方法 -
调方法：值接收者方法可用
reflect.ValueOf(u).MethodByName("X")；但指针接收者方法（如修改字段的）必须用reflect.ValueOf(&u).MethodByName("X")，否则Call后原值不变
参数传递也极敏感：调 Call 时，每个参数必须是 reflect.Value，且类型要和函数签名完全一致（int 和 int64 不兼容，自定义别名也不行）。
性能代价和替代思路
reflect 不是语法糖，它是运行时查表 + 类型断言 + 内存操作，开销远高于直接调用。实测显示，反射赋值比直接赋值慢 10–100 倍，取决于嵌套深度和字段数。
- 高频路径（如 HTTP 请求处理中间件）避免在每次请求里做全量结构体反射；可提前缓存
reflect.Type和字段偏移 - 简单场景优先考虑代码生成（
go:generate+stringer或自定义模板），把反射逻辑移到编译期 - 仅含基础字段的结构体，用
unsafe或encoding/json的底层structfield机制可能更轻量（但失去标签灵活性）
真正难的从来不是“怎么写反射”，而是判断“这里到底该不该用反射”——多数时候，把接口设计得更正交，比强行通用更可持续。
