如何避免Golang指针引发的空引用错误_Golang指针安全使用方式

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 输入并验证行为。

• 对每个接受指针参数的导出函数，至少写一个 nil 输入测试用例
• 检查日志、错误返回、是否 panic —— 根据设计决定是允许 panic 还是应优雅返回错误
• 用 go vet 和 staticcheck 可捕获部分明显未判空的解引用，但无法替代逻辑测试

func TestProcessUser_Nil(t *testing.T) {
    processUser(nil) // 应不 panic，或按约定返回 error
    // 断言日志、返回值等
}

空指针不是 Go 的缺陷，而是它的显式性要求。最易被忽略的点是：**函数签名里写了 *T，不代表调用方一定会传非 nil；而你写的每个 *T 参数，都得自己负责守门**。