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