Go反射不能直接实现通用序列化，它仅动态读取结构体字段并配合json.Marshal等函数控制序列化行为；reflect.Value需调用Interface()转回原始值才能序列化，私有字段和嵌套未导出字段会被json包忽略。
Go 的反射本身不能直接实现“通用序列化”，它只是辅助工具；真正做序列化的还是 json.Marshal、gob.Encode 这类函数。反射的作用是绕过硬编码字段名，动态读取结构体字段并控制序列化行为——但必须配合明确的序列化目标（如 JSON 字段名、忽略规则、嵌套处理）才能落地。
为什么直接用 reflect.Value.Interface() 无法正确序列化嵌套结构
常见误区是拿到结构体的 reflect.Value 后直接传给 json.Marshal，结果出现 json: unsupported type: reflect.Value 错误。这是因为 reflect.Value 不是可序列化类型，必须先调用 .Interface() 转回原始 Go 值。
-
reflect.Value是运行时描述，不是数据本身 - 若字段是私有（首字母小写），
Interface()返回的是不可寻址副本，json包默认跳过私有字段 - 嵌套结构体字段若未导出，即使外层能取到
reflect.Value，json仍无法访问其内部
如何用反射 + struct tag 控制 JSON 序列化字段名与忽略逻辑
Go 标准库的 json 包已内置反射支持，不需要手写反射遍历。但如果你需要在序列化前动态修改字段行为（比如根据环境开关某个字段），就得自己用反射提取字段并构造 map。
- 用
reflect.TypeOf(v).Field(i).Tag.Get("json")读取 struct tag，解析出字段名和选项（如"name,omitempty"） - 用
reflect.ValueOf(v).Field(i)获取对应值，再判断是否为零值（用于omitempty） - 手动组装
map[string]interface{}，再交给json.Marshal—— 这比直接序列化原结构体慢，但可控
示例关键片段：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
val := reflect.ValueOf(obj)
typ := reflect.TypeOf(obj)
result := make(map[string]interface{})
for i := 0; i < val.NumField(); i++ {
field := typ.Field(i)
jsonTag := field.Tag.Get("json")
if jsonTag == "-" || strings.HasPrefix(jsonTag, ",") {
continue
}
key := strings.Split(jsonTag, ",")[0]
if key == "" {
key = field.Name
}
fieldValue := val.Field(i)
if fieldValue.CanInterface() {
result[key] = fieldValue.Interface()
}
}
反射序列化性能差在哪？什么场景下值得优化
反射序列化比直接调用 json.Marshal 慢 3–10 倍，主要开销在：反复调用 reflect.Value.Field()、字符串切片解析 tag、动态构建 map、接口类型装箱（interface{}）。
- 高频 API 返回（如每秒上万次 HTTP 响应）不适合用反射拼接 JSON
- 适合场景：配置加载时一次性解析不同结构体、CLI 工具中打印任意结构体调试信息、ORM 层统一处理模型字段映射
- 若真需高性能通用序列化，优先考虑代码生成（如
easyjson或go:generate+stringer风格模板），而非运行时反射
真正难的不是“怎么用反射序列化”，而是判断哪些字段该进、哪些该按规则过滤、嵌套时要不要递归展开——这些逻辑一旦写死在反射循环里，就很难被编译器优化，也容易漏掉指针 nil 解引用或 interface{} 类型 panic。
