Go 的 reflect 包不能自动填充结构体字段，需手动实现遍历与赋值逻辑；常见坑包括操作不可寻址值、非导出字段、类型不匹配、nil 指针/切片/map 未初始化；应结合 struct tag 控制行为，校验 CanSet()，避免热路径使用，并明确业务规则而非依赖反射承担默认值或校验职责。
go 的 reflect 包不能“自动填充”结构体字段——它只提供运行时类型和值的读写能力，填充逻辑必须由你明确定义。所谓“自动”，其实是用反射遍历字段 + 按规则赋值，常见于配置解析、orm 映射或测试数据生成等场景。
为什么直接用 reflect.Set() 常失败
最常踩的坑是：对非可寻址（unaddressable）值调用 reflect.Value.Set() 会 panic，错误信息是 reflect: reflect.Value.Set using unaddressable value。这是因为 reflect.Value 默认操作的是值的副本，而非原变量本身。
- 必须用
reflect.ValueOf(&v).Elem()获取可寻址的结构体 Value - 字段必须是导出的（首字母大写），否则
reflect.Value.Field()无法访问 - 目标字段类型与待赋值类型不匹配时，
Set()会 panic，需手动类型转换或跳过 - nil 指针字段（如
*string）不能直接SetString()，得先SetNil()或Set(reflect.New())
用 reflect.StructField.Tag 控制填充行为
结构体字段 tag（如 json:"name" 或 fill:"default=unknown"）是驱动“自动填充”的关键元数据。反射本身不解析 tag，但你可以用 structField.Tag.Get("fill") 提取并解析自定义规则。
- 推荐用
structs（第三方库）或手写简单 parser 解析 tag 字符串，例如fill:"default=abc,required" - tag 中的
required可触发校验，缺失时返回 error；default可用于设置默认值 - 避免在 tag 中嵌入复杂逻辑（如表达式），保持字符串可读、易解析
- 注意：tag 值是字符串字面量，不会被 Go 编译器校验，拼错就静默失效
填充 nil 切片、map 和指针字段的典型处理
结构体中声明为 []int、map[string]string 或 *int 的字段，若未初始化，其 reflect.Value 是 nil，直接 Set() 会 panic。必须按类型分别初始化：
-
[]T：用reflect.MakeSlice(reflect.SliceOf(t), 0, 0)创建空切片 -
map[K]V：用reflect.MakeMap(reflect.MapOf(kType, vType)) -
*T：用reflect.New(tType).Elem()得到可寻址的T值，再设具体值 - 注意：不要对已非 nil 的字段重复初始化，应先判断
v.IsNil()
性能与安全边界：别在热路径用反射填充
反射操作比直接赋值慢 10–100 倍，且绕过编译期类型检查。生产环境高频调用（如 HTTP 请求解包）应优先考虑代码生成（go:generate + stringer 风格）或专用 struct map（如 map[string]interface{} 转 struct 的预编译函数）。
- 反射适合低频、动态场景：CLI 参数绑定、测试 fixture 构造、配置文件反序列化后二次补全
- 永远校验
CanSet()再调用Set()，尤其处理嵌套结构体时，某层可能不可寻址 - 对用户输入或外部数据做反射填充前，务必限制字段白名单，防止通过恶意字段名写入私有/敏感字段
真正难的不是遍历字段，而是决定每个字段“该填什么”——默认值来源、类型转换策略、嵌套结构递归深度、错误聚合方式，这些逻辑一旦脱离反射本身，就变成业务规则问题。别让 reflect 承担本该由配置或类型系统承担的责任。
