反射仅适用于运行时动态操作类型和值的场景，如序列化工具、ORM框架；reflect.ValueOf默认返回副本，需传指针并调用Elem()才能修改原变量，且仅导出字段在结构体可寻址时才可写。
Go 的反射不是万能胶，用错地方反而让代码更难维护；它只在真正需要运行时动态操作类型和值时才值得用，比如写通用序列化工具、ORM 框架或测试辅助函数。
为什么 reflect.ValueOf 返回的值不能直接修改变量？
因为 reflect.ValueOf 默认返回的是原值的副本（除非显式传入指针）。对副本调用 Set* 方法会 panic：「reflect: reflect.Value.Set using unaddressable value」。
- 要修改原始变量，必须传入指针：
reflect.ValueOf(&x)，再用.Elem()获取可寻址的值 - 原始值本身不可寻址（如字面量、函数返回值）时，即使加了
&也会编译失败，这时反射根本无法修改 - 结构体字段只有导出（大写开头）且所在结构体本身可寻址，才能被
Set
如何安全地用反射遍历结构体字段并读取 tag？
常见于 JSON/YAML 解析、校验库中提取 json: 或 validate: 标签。关键点是：先确认是结构体、再确认字段导出、再检查 tag 是否非空。
val := reflect.ValueOf(obj)
typ := reflect.TypeOf(obj)
if val.Kind() == reflect.Ptr {
val = val.Elem()
typ = typ.Elem()
}
if typ.Kind() != reflect.Struct {
return
}
for i := 0; i < typ.NumField(); i++ {
field := typ.Field(i)
if !val.Field(i).CanInterface() { // 非导出字段无法取值
continue
}
jsonTag := field.Tag.Get("json")
if jsonTag == "" || jsonTag == "-" {
continue
}
// 处理字段名和值，例如：field.Name → val.Field(i).Interface()
}
reflect.DeepEqual 看似方便，但为什么线上慎用？
它会递归比较任意嵌套结构，性能差、不透明、且对某些类型行为反直觉（比如 func 类型恒等为 false，map 的键顺序不同会导致误判）。
立即学习“go语言免费学习笔记（深入）”；
- 单元测试里用没问题，但服务中用于高频数据比对（如缓存 key 判定、状态 diff）会显著拖慢吞吐
- 浮点数比较不处理 NaN / ±0 边界，时间类型忽略位置（
time.Time的 zone 信息可能丢失） - 更可控的做法是：为业务类型显式实现
Equal()方法，或用cmp.Equal（来自 golang.org/x/exp/cmp）并自定义选项
反射调用方法时，Call 和 CallSlice 有什么实质区别？
区别只在参数传入方式：前者接收 []reflect.Value，后者接收单个 reflect.Value（该值本身必须是切片类型）。
- 如果你已有参数切片
args := []reflect.Value{...}，用method.Call(args) - 如果参数已打包成一个
reflect.Value（比如从 JSON 反序列化来的 slice），用method.CallSlice(argsSlice) - 两者最终行为完全一致，选哪个取决于你手头数据的形态，别为了用
CallSlice而额外构造切片值
反射真正的复杂点不在语法，而在于它把编译期确定的东西挪到运行时——类型安全、IDE 跳转、静态分析全失效。哪怕只是读 struct tag，也要多想一层：这个字段名会不会拼错？tag 值格式有没有文档约束？一旦出错，panic 发生在深夜三点的线上服务里，堆栈里只剩 reflect.Value.SetString 这一行。
