当结构体嵌入了实现 `json.unmarshaler` 接口的类型时，go 的 `json.unmarshal` 会直接调用该嵌入类型的 `unmarshaljson` 方法，跳过对整个外层结构体的字段解析，导致其他嵌入字段（如 `user`）被忽略。
这是 Go 类型系统与 encoding/json 包协同工作的预期行为，而非 bug。其根本原因在于：json.Unmarshal 在解码前会通过反射检查目标值是否实现了 json.Unmarshaler 接口（即 v.Interface().(json.Unmarshaler)）。一旦发现 *ServiceAccount 满足该条件（因其嵌入了 *Policy，而 *Policy 实现了 UnmarshalJSON），它便会*直接调用 `(Policy).UnmarshalJSON**，并将原始 JSON 数据全部交由该方法处理——此时json包不再尝试逐字段解码ServiceAccount的其余部分（包括User` 字段），因为“接口已接管”。
为什么 ServiceAccount 被认为实现了 Unmarshaler？
根据 Go 规范，结构体类型若嵌入了实现某接口的字段，则该结构体自动获得该接口的实现（前提是嵌入字段是可导出的、且方法集完整）。由于 Policy 是可导出类型，且 *Policy 实现了 UnmarshalJSON，因此 *ServiceAccount 自动满足 json.Unmarshaler 接口。这正是 json 包选择跳过默认结构体解码逻辑的关键依据。
验证：嵌入多个 Unmarshaler 会发生什么？
有趣的是，若同时为 User 和 Policy 实现 UnmarshalJSON，*ServiceAccount 将不再实现 json.Unmarshaler——因为此时存在方法冲突（两个嵌入类型都提供同名方法），Go 无法明确选择哪一个，故从方法集中排除 UnmarshalJSON。你可以通过显式调用 srvAcc.UnmarshalJSON(...) 触发编译错误 "ambiguous selector" 来验证这一点。但需注意：即使如此，json.Unmarshal 也不会自动分别调用各嵌入类型的 UnmarshalJSON；它只会回退到默认的字段映射逻辑（即正常解码所有字段）。
正确解决方案（推荐顺序）
✅ 方案一：避免嵌入 Unmarshaler 类型（最清晰）
改用命名字段，显式控制解码逻辑：
type ServiceAccount struct {
User User `json:"user,omitempty"`
Policy Policy `json:"policy,omitempty"`
}这样 ServiceAccount 不再隐式实现 Unmarshaler，json 包将按字段标签正常解码。
✅ 方案二：在外层类型显式实现 UnmarshalJSON（最可控）
完全掌控解码流程，兼顾嵌入字段：
func (s *ServiceAccount) UnmarshalJSON(data []byte) error {
// 1. 先解码到临时结构体（避免递归调用）
type Alias ServiceAccount // 防止无限递归
aux := &struct {
UserID string `json:"userID"`
Scopes string `json:"scopes,omitempty"`
*Alias
}{
Alias: (*Alias)(s),
}
if err := json.Unmarshal(data, &aux); err != nil {
return err
}
s.User.UserID = aux.UserID
s.Policy.Scopes = aux.Scopes
return nil
}⚠️ 方案三：慎用“多嵌入 Unmarshaler”技巧
虽能迫使 ServiceAccount 失去 Unmarshaler 实现，但属于反模式，易引发维护困惑，不推荐。
总结
- 嵌入 Unmarshaler 类型会“劫持”整个外层结构体的 JSON 解码流程；
- 这是 Go 接口实现规则与 json 包设计逻辑共同作用的结果；
- 最佳实践是：要么避免嵌入 Unmarshaler，要么主动在外层类型中实现完整解码逻辑；
- 始终优先考虑代码可读性与可维护性，而非依赖反射或接口继承的隐式行为。
