应根据是否允许为 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 的其他代码——除非它们也通过同一指针访问。
立即学习“go语言免费学习笔记（深入）”；
- 嵌套值字段（
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 可能来自字段未查询、未设置、或业务逻辑主动置空，三者无法靠指针状态区分。
