结构体指针安全判空需显式用 if p == nil 检查，嵌套访问须逐层判断（如 user != nil → user.Address != nil → user.Address.City），方法接收者为 *T 时仅在访问字段前判 nil，json.Unmarshal 后指针字段仍可能为 nil 需手动初始化。
结构体指针是否为 nil 怎么安全判断
Go 里没有“空结构体引用”的概念，只有 *T 类型的指针可能为 nil。直接对 nil 结构体指针取字段（比如 p.Name）会 panic：invalid memory address or nil pointer dereference。
最直接、最安全的做法就是显式判 nil：
- 用
if p == nil判断指针本身是否为空，再决定是否访问其字段 - 不要依赖结构体内字段是否“零值”来反推指针是否为空（比如
p.Name == ""不代表p非空） - 如果函数接收
*T参数，且逻辑上允许nil，必须在开头加if p == nil分支，否则上线后大概率 crash
嵌套结构体指针怎么逐层防 panic
常见场景：比如 user.Address.City，而 user 或 user.Address 都可能是 nil。不能只判第一层，必须每级解引用前都检查。
典型错误写法：if user.Address != nil && user.Address.City != "" —— 如果 user 是 nil，这行代码根本跑不到右边就 panic 了。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 正确顺序是：先
if user != nil，再if user.Address != nil，最后才访问user.Address.City - 可以提前 return 或用短路逻辑封装成辅助函数，比如
safeGetCity(u *User) string，内部做完整链路判空 - 别图省事用
reflect或第三方库自动解包——运行时开销大、类型不安全、报错不直观
方法接收者是 *T 时，nil 指针调用会不会 panic
Go 允许 nil 指针调用方法，但前提是方法体内没访问任何字段或调用其他非 nil 安全的方法。
- 如果方法只做逻辑判断、返回固定值、或只调用自身其他
nil安全方法，可以不判空（例如func (u *User) IsEmpty() bool { return u == nil || u.ID == 0 }） - 只要一出现
u.Name、u.Email.String()这类字段/方法访问，就必须在方法开头加if u == nil - 注意：接口变量存储
nil指针时，if iface == nil判的是接口本身是否为 nil，不是底层指针——这是另一个常见混淆点
json.Unmarshal 后结构体字段为什么还是 nil
JSON 解析不会自动初始化嵌套指针字段。比如结构体里有 Address *Address，即使 JSON 里有 "address": {...}，Address 字段也可能是 nil —— 因为 Go 的默认零值是 nil，而 json.Unmarshal 只会赋值非零字段，不会主动 new。
- 确认字段是否被成功解析：打印
fmt.Printf("%+v", user)，看Address是&{...}还是<nil></nil> - 如果业务逻辑依赖该字段非空，应在 Unmarshal 后手动补判：
if user.Address == nil { user.Address = &Address{} } - 更健壮的做法是在结构体定义时用指针包装 + 自定义
UnmarshalJSON方法，或改用值类型（Address Address）避免指针判空负担
真正麻烦的不是“怎么写判空”，而是哪些地方**漏判了**——尤其在多人协作、中间件透传、JSON 动态解析等场景下，nil 往往藏得深，panic 时堆栈还未必指向你写的那行字段访问。
