应根据是否允许为 nil 决定：需表达“不存在”用 *T，必须存在用 T；值类型总有零值，指针可为 nil 以区分“空”与“默认”；性能非首要考量。

嵌套结构体字段用 *T 还是 T？看是否允许为 nil

Go 中嵌套结构体时，字段声明为指针类型（*T）还是值类型（T），核心判断依据是：该字段是否需要表达「不存在」或「未初始化」语义。值类型字段永远存在且有零值（比如 0、""、nil 切片），而指针字段可为 nil，能明确区分「空」和「默认值」。

常见误用场景：把所有嵌套都写成指针，只为避免拷贝——这反而增加 nil panic 风险，且掩盖业务语义。

• 用 *User：当嵌套的用户信息可能完全缺失（如订单无买家信息），且上层逻辑需显式检查 if order.Buyer == nil
• 用 User：当每个订单必须关联一个有效用户（哪怕只是空结构体占位），且不允许 nil
• 性能不是首要理由：小结构体（

json.Unmarshal 对嵌套指针字段的静默行为

JSON 反序列化时，json 包对指针字段的处理容易引发意外：如果 JSON 中对应字段缺失或为 null，*T 字段会被设为 nil；但如果字段存在但值非法（比如字符串塞进 *int），会保留原指针值（可能是野指针或旧值），不报错也不清空。

type Order struct {
    ID     int     `json:"id"`
    Buyer  *User   `json:"buyer"`
    Items  []Item  `json:"items"`
}

// 输入 {"id": 123, "buyer": null} → Buyer 被设为 nil
// 输入 {"id": 123} → Buyer 也被设为 nil（字段缺失）
// 输入 {"id": 123, "buyer": "invalid"} → Buyer 保持原值（不会变 nil，也不会 panic）

• 务必在反序列化后检查关键指针字段是否为 nil，尤其涉及数据库写入或业务校验时
• 若希望缺失字段保留旧值（如 patch 更新），用指针；若希望缺失即重置为零值，用值类型 + 自定义 UnmarshalJSON
• 避免混合使用：同一结构体中部分嵌套用指针、部分用值，会让 JSON 行为难以预测

方法接收者与嵌套字段修改的连带影响

当结构体方法使用指针接收者（func (o *Order) SetStatus(s string)），它能安全修改自身字段，包括嵌套的值类型字段（如 o.User.Name = "A"）。但如果嵌套字段本身是指针（User *User），方法内对 o.User 的赋值（o.User = &User{...}）只影响当前指针变量，不影响外部持有该 *Order 的其他代码——除非它们也通过同一指针访问。

• 嵌套值字段（User User）：方法内可直接改其内部字段，调用方可见变化
• 嵌套指针字段（User *User）：方法内 o.User.Name = "X" 会生效（改所指对象）；但 o.User = new(User) 不会影响调用方持有的旧指针
• 如果嵌套结构体本身有指针接收者方法，注意不要在父结构体方法中误调用 o.User.DoSomething() 而 o.User 为 nil —— 这会 panic

数据库 ORM（如 GORM）映射时的指针陷阱

GORM 等 ORM 默认将结构体字段按值映射到数据库列，但遇到指针字段（*string、*time.Time）时，会将其视为「可空字段」，生成 SQL 的 NULL 允许标记。而嵌套结构体指针（如 *Address）会被忽略（GORM 不递归解析指针内的结构体），除非显式启用 Embedded 或自定义 Scanner/Valuer。

• type Order { Address *Address `gorm:"embedded"` }：仅当 *Address 非 nil 时才嵌入字段；若为 nil，所有 Address 相关列存为 NULL
• 若想让 Address 字段强制非空，应声明为 Address Address，并确保迁移时没加 NULL
• 查询时若用 SELECT * 但 Address 在 DB 中为 NULL，GORM 会把 *Address 设为 nil；但若用 SELECT id,name 漏掉 Address 列，*Address 仍为 nil —— 容易误判为数据缺失而非查询裁剪

最常被忽略的是：嵌套指针字段在 JSON 和数据库之间语义不一致——JSON 里 null 映射为 nil，但数据库里 NULL 可能来自字段未查询、未设置、或业务逻辑主动置空，三者无法靠指针状态区分。