嵌套结构体中该用 T 还是 T，取决于字段是否可为空及是否需共享状态：允许 nil 或需多处同步修改时用 T，否则优先用 T；小结构体用值类型更高效，大结构体才考虑指针。
嵌套结构体里该用 *T 还是 T？看字段是否可为空和是否需共享状态
Go 中结构体嵌套时用指针还是值类型，核心取决于两个实际需求：字段是否允许为 nil（比如可选配置），以及是否希望多个结构体实例共享同一份数据。比如 type User struct { Profile *Profile } 表示 Profile 可选；而 type User struct { Profile Profile } 强制存在且每次复制都独立拷贝。
常见错误是盲目用指针避免拷贝——但小结构体（如 Point {x, y int}）用值类型更高效；大结构体（含切片、map 或大量字段）才值得用指针减少内存开销。
- 如果嵌套字段可能未初始化（如 API 响应中某些字段缺失），必须用
*T，否则零值会掩盖缺失语义 - 如果嵌套字段在多个地方被修改且需同步生效（如共享的连接池配置），用
*T是唯一选择 - 如果嵌套字段只读、体积小、逻辑上属于“整体一部分”（如
Address之于User），优先用T
json.Unmarshal 对嵌套指针字段的默认行为很关键
JSON 解析时，json 包对 *T 字段的处理是：遇到 null 或字段缺失，自动设为 nil；遇到有效 JSON 对象，则分配新 T 并解码进去。而 T 字段遇到缺失时只会设为零值，无法区分“没传”和“传了零值”。
例如：
立即学习“go语言免费学习笔记（深入）”；
type Resp struct {
Data *User `json:"data"`
}
当 JSON 是 {"data": null}，resp.Data 为 nil；当是 {"data": {}}，resp.Data 是非空指针，内部字段为零值；当字段完全不存在，resp.Data 仍是 nil。这个特性常被用来做字段存在性判断。
- 别在
jsontag 里加omitempty同时又用*T——这会导致“零值字段不输出”和“nil 字段也不输出”混在一起，反向解析时无法还原原意 - 如果想让
nil *T在 JSON 中输出为null（而不是忽略），确保没加omitempty，且结构体字段名首字母大写
初始化嵌套指针字段容易漏掉 & 或 new()
声明含 *T 字段的结构体变量后，该字段初始值是 nil。直接访问其内部字段会 panic：panic: runtime error: invalid memory address or nil pointer dereference。必须显式分配内存。
正确方式有三种：
- 字面量初始化：
u := User{Profile: &Profile{Name: "Alice"}} - 先声明再赋值：
u := User{}; u.Profile = &Profile{Name: "Alice"} - 用
new()：u.Profile = new(Profile); u.Profile.Name = "Alice"
注意：不要写 u.Profile = Profile{Name: "Alice"}——这是类型错误，右边是值，左边是 *Profile。
方法接收者与嵌套指针字段的耦合容易被忽略
如果嵌套字段是 *T，而你又给 T 定义了指针接收者方法（如 func (p *Profile) Validate() error），那么即使外层结构体字段是 *Profile，调用 user.Profile.Validate() 也没问题。但若 Validate 是值接收者，user.Profile 是 *Profile 也能调用（Go 自动解引用）——这点常让人误以为“指针字段配值接收者也行”，其实只是语法糖。
真正要注意的是：如果外层结构体字段是 Profile（值类型），而你想调用 *Profile 接收者方法，就必须取地址：&user.Profile.Validate()。否则编译报错：cannot call pointer method on user.Profile。
所以设计时得通盘考虑：嵌套字段类型、方法接收者类型、以及谁负责生命周期管理。一个典型坑是，在方法里对 *T 字段做了修改，但调用方传入的是值类型副本，结果改了白改。
