Go中解引用指针前必须显式检查是否为nil，否则会panic；需警惕函数返回值、结构体未初始化字段、map未make、接口底层为nil指针等场景。
检查指针是否为 nil 再解引用
Go 不会自动做空指针防护，nil 指针一解引用就 panic，错误信息通常是 panic: runtime error: invalid memory address or nil pointer dereference。这不是运行时能“绕过”的问题，必须在解引用前显式判断。
常见错误场景：函数返回指针但没校验、结构体字段未初始化、map 中取值后直接调用方法。
- 所有可能为
nil的指针变量，在调用其方法或访问其字段前，先写if p != nil - 不要依赖“它应该不为 nil”——比如
json.Unmarshal对指针字段赋值失败时，该字段仍为nil - 对函数返回的指针（如
http.NewRequest、os.Open），即使文档说“成功时不返回 nil”，也要看它是否可能返回nil；os.Open返回*os.File，出错时返回nil, err，必须先判 err 再用指针
用结构体字面量初始化避免零值陷阱
结构体字段若声明为指针类型（如 *string、*int），用 var s MyStruct 或 MyStruct{} 初始化后，这些字段默认就是 nil。后续若直接解引用，必 panic。
典型踩坑点：API 请求结构体中混用值类型和指针类型字段，前端没传某字段 → 后端反序列化后该指针字段为 nil → 日志打印或业务逻辑里直接 *s.Field 就崩。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 明确哪些字段允许为空：如果允许为空，用指针；否则统一用值类型（
string而非*string） - 构造结构体时，宁可显式赋零值也不依赖默认
nil：比如&MyStruct{Field: new(string)}或field := ""+&field - 用
go vet可捕获部分未初始化指针字段的潜在风险，但不能替代逻辑判断
map 和 slice 的 nil 判定要区分语义
nil map 和 nil slice 在 Go 中是合法状态，但行为不同：nil map 读写都 panic（assignment to entry in nil map），nil slice 读不 panic（长度为 0），但写（append）可以，只是要注意容量。
很多人误以为 “map 是引用类型所以不会 nil”，其实 map 变量本身可以是 nil，尤其在函数参数传递或嵌套结构体中容易遗漏初始化。
- 声明 map 后务必初始化：用
m := make(map[string]int)，而不是var m map[string]int - 接收 map 参数的函数，开头加
if m == nil { return }或按需初始化，别假设调用方一定传了非 nil 值 - 对 map 的 key 查找结果（
v, ok := m[k]）不能代替nil检查——m本身为nil时这行代码就 panic 了
接口变量的 nil 判断有隐藏陷阱
接口变量为 nil 时，它内部的动态类型和动态值都为空；但如果接口变量里存了一个 nil 指针（比如 *os.File(nil)），整个接口变量**不是 nil**，此时直接调用方法会 panic。
这是最隐蔽的 Nil Pointer Dereference 来源之一：你以为判了 if x != nil 就安全了，其实只是判了接口非 nil，没判底层值是否为空。
- 对接受接口参数的函数（如
io.Reader、error），不能只靠x != nil防护；若知道底层可能是指针，应做类型断言后二次判空：if r, ok := x.(interface{ Close() error }); ok && r != nil不够，得再确认r底层是否真有效 - 自定义接口实现时，避免在方法里直接解引用未检查的字段指针；优先在方法入口做
if p.field == nil判定 - 日志或调试时，用
fmt.Printf("%+v", x)看接口底层值，比单纯== nil更可靠
最难防的不是明面上的 nil，而是那些“看起来不该为 nil 却偏偏是 nil”的组合：未导出字段、嵌套结构体中的指针、第三方库返回的泛型接口。每次解引用前多一次 != nil 判断，成本极低，但能拦下绝大多数崩溃。
