用 reflect.StructField.Anonymous 可准确判断字段是否为匿名嵌入，仅编译器标记的匿名字段该值为 true；显式命名字段即使小写或类型名相同也非匿名，需用 Field(i) 按索引访问而非 FieldByName。
用 reflect.StructField.Anonymous 判断字段是否为匿名字段
Go 的反射中，reflect.StructField 有一个 Anonymous 字段（布尔值），它直接告诉你这个字段是不是匿名嵌入的。不是靠名字判断，也不是靠类型名匹配——只有编译器标记为“匿名嵌入”的字段，该字段才为 true。
常见错误是以为字段名和类型名相同就是匿名字段，比如 type User struct { Person } 中的 Person 是匿名字段；但 type User struct { p Person } 就不是，哪怕 p 是小写、没导出，只要显式写了字段名，Anonymous 就是 false。
- 必须先用
reflect.TypeOf(t).Elem()（若t是指针）或reflect.TypeOf(t)获取结构体类型 - 遍历
Type.NumField()，对每个Type.Field(i)检查.Anonymous - 注意：嵌套匿名结构体的字段不会自动“扁平化”到外层 —— 只有直接声明的匿名字段才被标记为
Anonymous: true
读取匿名字段的值要用 reflect.Value.Field(i) 而非 FieldByName
匿名字段没有名字，所以 Value.FieldByName("Person") 会返回零值 + ok=false。必须用序号访问，或者先拿到字段类型再按索引取值。
例如结构体 type A struct { B; C int }，其中 B 是匿名字段，A 的字段数是 2，Field(0) 对应 B，Field(1) 对应 C。不能假设 B 一定在第 0 位 —— 如果定义是 type A struct { C int; B }，那 B 就是 Field(1)。
立即学习“go语言免费学习笔记（深入）”；
-
Value.Field(i)返回的是该字段的reflect.Value，可继续调用.Interface()或递归反射 - 如果要“展开”匿名字段（即把
B的所有公开字段挂到A下），得手动遍历B的字段并拼接路径，标准库不提供自动扁平化 - 注意
Value必须可寻址（如传入指针）才能修改匿名字段里的值，否则SetXxx会 panic
嵌套匿名字段的字段名冲突时，FieldByName 只返回第一个匹配项
当多个匿名字段包含同名导出字段（如两个匿名字段都有 ID int），Value.FieldByName("ID") 仍会返回 ok=true，但它只返回**第一个**声明顺序上的那个字段的值 —— 不报错，也不警告。
这容易导致静默错误。比如：
type A struct{ ID int }
type B struct{ ID int }
type C struct{ A; B }
c := C{A: A{ID: 1}, B: B{ID: 2}}
v := reflect.ValueOf(c)
id := v.FieldByName("ID").Int() // 返回 1，不是 2，也不是报错
- 这种行为是 Go 反射的明确设计，不是 bug
- 若需区分，必须用
NumField()遍历，检查每个字段的Type.Name()和Anonymous，再进入其内部找ID - JSON 或 Gob 序列化也遵循同样规则：同名字段只序列化第一个
性能与安全提醒：反射读匿名字段比直接访问慢 10–100 倍，且绕过类型检查
每次调用 reflect.Value.Field(i) 或 reflect.Value.FieldByName 都涉及运行时类型查找、边界检查和接口分配。在 hot path（如 HTTP handler 内部）频繁使用会明显拖慢吞吐。
- 如果结构体形状固定，优先用生成代码（如
go:generate+structfield）代替运行时反射 - 避免在循环内重复调用
reflect.TypeOf(x)—— 提前缓存reflect.Type和字段索引映射 - 反射无法检测未导出字段的赋值权限：即使字段是匿名的，若其内部字段未导出（如
type A struct{ name string }），FieldByName("name").CanSet()仍为false
匿名字段的反射读取本身不复杂，真正麻烦的是嵌套层级、命名冲突和性能隐忧 —— 这些地方不提前想清楚，上线后 debug 成本远高于写时多花的两分钟。
