当 Go 结构体嵌入（embedding）了带有自定义 UnmarshalJSON 方法的子结构体时，json.Unmarshal 会优先调用该方法，导致外层字段（如 Num）被忽略；解决方法是避免在嵌入类型中定义 UnmarshalJSON，改用 JSON 标签控制字段映射，或重构为组合模式。
当 go 结构体嵌入（embedding）了带有自定义 `unmarshaljson` 方法的子结构体时，`json.unmarshal` 会优先调用该方法，导致外层字段（如 `num`）被忽略；解决方法是避免在嵌入类型中定义 `unmarshaljson`，改用 json 标签控制字段映射，或重构为组合模式。
在 Go 中，嵌入结构体（anonymous field）虽能实现字段继承式访问，但在 JSON 反序列化场景下易引发意外行为——尤其当嵌入类型实现了 UnmarshalJSON 方法时。Go 的 encoding/json 包在遇到嵌入字段且其类型实现了 UnmarshalJSON 接口时，会完全委托该方法处理整个原始 JSON 数据，而不再解析外层结构体的其他字段（如 Num），从而导致数据丢失。
✅ 推荐方案：优先使用 JSON 标签（最简洁、最符合 Go 惯例）
若 Inner 仅包含基础字段（如 string、int 等），无需复杂逻辑，应直接移除自定义 UnmarshalJSON，改用标准 JSON 标签：
type Outer struct {
Inner `json:",inline"` // 显式声明内联，确保 Inner 字段展开
Num int `json:"num"`
}
type Inner struct {
Data string `json:"data"`
}
? 关键点：json:",inline" 是可选但强烈推荐的标签，它明确告诉 json 包将 Inner 的字段“扁平化”到 Outer 的 JSON 层级中（等效于直接定义 Data string）。即使省略，Go 也会默认 inline 嵌入字段，但显式标注更清晰、可维护性更强。
示例反序列化：
data := []byte(`{"data": "hello", "num": 42}`)
var o Outer
err := json.Unmarshal(data, &o)
if err != nil {
log.Fatal(err)
}
fmt.Printf("%+v\n", o) // {Inner:{Data:"hello"} Num:42}
⚠️ 替代方案：改用组合（Composition），而非嵌入（Embedding）
当 Inner 确实需要自定义反序列化逻辑（例如解析非标准格式、校验、转换），则不应嵌入，而应作为命名字段显式组合，并为其单独实现 UnmarshalJSON：
type Outer struct {
Data Inner `json:"data"`
Num int `json:"num"`
}
type Inner struct {
Thing string `json:"thing"`
OtherThing int `json:"otherThing"`
}
// 仅对 Inner 实现自定义 UnmarshalJSON（作用域明确，不影响 Outer）
func (i *Inner) UnmarshalJSON(data []byte) error {
// 示例：支持字符串或对象两种输入格式
var raw map[string]interface{}
if err := json.Unmarshal(data, &raw); err == nil {
// 解析为对象
return json.Unmarshal(data, i)
}
// 否则尝试解析为字符串
var s string
if err := json.Unmarshal(data, &s); err != nil {
return err
}
i.Thing = s
return nil
}
此方式职责清晰：Inner 控制自身字段解析，Outer 由标准 json 包处理，二者互不干扰。
❌ 不推荐：在嵌入类型中实现 UnmarshalJSON
原问题中的写法存在根本性缺陷：
type Inner struct { Data string }
func (i *Inner) UnmarshalJSON(data []byte) error {
i.Data = string(data) // 直接将原始 JSON 字节赋值给 string → 完全绕过结构体解析！
return nil
}
这会导致：
- {"data":"x","num":1} 被整体传入 Inner.UnmarshalJSON，i.Data 变成 "{"data":"x","num":1}"；
- Outer.Num 永远得不到赋值；
- 丧失类型安全与字段校验能力。
✅ 总结建议
| 场景 | 推荐做法 |
|---|---|
| Inner 仅含简单字段（无特殊解析需求） | 移除 UnmarshalJSON，使用 json 标签 + ",inline" |
| Inner 需要灵活/容错解析（如多格式兼容、预处理） | 改用组合（命名字段），独立实现 UnmarshalJSON |
| 必须保留嵌入语法且需自定义逻辑 | 重写 Outer.UnmarshalJSON 全局接管（复杂，一般不推荐） |
记住：Go 的 JSON 包设计哲学是「约定优于配置」。90% 的场景下，合理使用 json struct tags 就足够健壮、高效且易于理解——过度依赖自定义 UnmarshalJSON 往往是设计信号：结构可能需要重构，而非强行适配。
