Go中需显式检查指针是否为nil再解引用，因nil指针解引用会直接panic；所有可能为nil的指针（如函数返回、map查找、结构体字段等）都必须判空，常见场景包括json.Unmarshal后、HTTP请求嵌套字段、sql.NullString等。
检查指针是否为 nil 再解引用
Go 不会自动做空指针防护，nil 指针解引用直接 panic，错误信息通常是 panic: runtime error: invalid memory address or nil pointer dereference。必须在使用前显式判断。
- 所有从函数返回、结构体字段、map 查找、切片索引得到的指针，只要可能为
nil，都需先判空 - 常见高危场景：调用
json.Unmarshal后未检查返回指针、接收 HTTP 请求中嵌套结构体字段、数据库查询结果为sql.NullString等包装类型内部指针 - 避免写成
if p != nil { use(*p) }这类重复解引用；更安全的是提前 return 或封装为 guard clause
func processUser(u *User) {
if u == nil {
log.Println("user is nil")
return
}
fmt.Println(u.Name) // 安全
}
初始化指针时明确来源，避免隐式零值
声明但未初始化的指针变量默认是 nil，比如 var p *int。这类变量若被误用，极易触发 panic。应尽量让指针有明确、可控的初始化路径。
- 用
&T{}显式取地址，而非依赖未赋值变量 - 构造函数（如
NewUser()）应保证返回非nil指针，或文档注明可能返回nil并说明条件 - 慎用
new(T)：它只做零值分配，对复杂结构体（含嵌套指针字段）不递归初始化，仍可能产生内部nil字段
type Config struct {
DB *sql.DB
}
// ❌ 危险：c.DB 是 nil，后续 c.DB.Query() panic
c := new(Config)
// ✅ 推荐：显式初始化关键字段，或用构造函数
c := &Config{DB: db} // db 已确认非 nil
用结构体嵌入 + 值语义替代深层指针链
长指针链（如 a.b.c.d.e.Name）是空引用错误的温床——任意一环为 nil 就崩。Go 更适合用组合和值语义降低间接层级。
- 把深层嵌套指针字段改为内嵌结构体或直接值类型（如
Time而非*time.Time） - 对可选字段，用
sql.NullString、optional.Option[T]（第三方库）等显式表达“存在/不存在”，而非裸指针 - API 接口接收参数时，优先用结构体值类型传参；仅当需要修改原值或节省拷贝开销时才用指针
type Order struct {
ID int
Status string
// ❌ 避免：User *User → User.Address.*string → 多层 nil 风险
// ✅ 改为：
UserID int
Address string // 或 sql.NullString
}
测试中覆盖 nil 指针边界用例
单元测试常忽略指针为 nil 的分支，导致线上 panic。要主动构造 nil 输入并验证行为。
立即学习“go语言免费学习笔记（深入）”；
- 对每个接受指针参数的导出函数，至少写一个
nil输入测试用例 - 检查日志、错误返回、是否 panic —— 根据设计决定是允许 panic 还是应优雅返回错误
- 用
go vet和staticcheck可捕获部分明显未判空的解引用，但无法替代逻辑测试
func TestProcessUser_Nil(t *testing.T) {
processUser(nil) // 应不 panic，或按约定返回 error
// 断言日志、返回值等
}
空指针不是 Go 的缺陷，而是它的显式性要求。最易被忽略的点是：**函数签名里写了 *T，不代表调用方一定会传非 nil；而你写的每个 *T 参数，都得自己负责守门**。 
