go中nil检查必须在解引用前进行，否则会直接panic；需对指针、map、slice等显式判空，注意interface{}的“带类型nil”陷阱，函数返回值要先检error再检指针，结构体优先用零值而非裸指针字段。
nil 检查必须在解引用前做
Go 中对 nil 指针、切片、map、channel、func 或 interface 解引用会直接 panic，比如 panic: runtime error: invalid memory address or nil pointer dereference。这不是运行时“警告”，而是立即崩溃。所以只要变量可能为 nil，且你要访问它的字段、调用其方法、或传给需要非空值的函数，就必须先显式判断。
常见错误场景包括：从 map 获取结构体指针后直接访问字段、函数返回 *User 但没检查就调 user.Name、接收参数是 map[string]interface{} 却直接取 m["data"].(map[string]interface{})。
- 切片和 map 的
len()和cap()可以安全用于nil值（len(nil) == 0），但range也可以，无需提前判空 - interface{} 类型变量为
nil时，其底层值和类型都为空；但var v interface{} = (*string)(nil)是非nilinterface，解包会 panic —— 这种“带类型的 nil”最容易误判 - 用
if v != nil判断 interface{} 是否为空，只在它确实未被赋值时有效；若你存了(*T)(nil)，这个判断会通过，但后续解引用仍 panic
函数返回值中的 *T 和 error 要成对处理
Go 标准库和主流风格约定：当函数可能失败并返回指针时，总是同时返回 error。不能只检查 err == nil 就认为指针可用 —— 有些实现会在出错时返回 nil, err，但也有些（尤其自定义逻辑）可能返回 non-nil-pointer, err（比如部分初始化对象），或更糟：返回 nil, nil（逻辑缺陷）。
实操建议始终按顺序检查：
立即学习“go语言免费学习笔记（深入）”；
- 先看
err != nil，有错优先处理错误 - 再确认指针是否非
nil：if user != nil && user.ID > 0，而非假设err == nil就一定有有效值 - 对数据库查询等场景，习惯写
if user == nil { return fmt.Errorf("user not found") }，比依赖err更直觉可靠
使用 struct 字段零值替代裸指针字段
定义结构体时，除非明确需要区分“未设置”和“设为空值”，否则避免用 *string、*int 等指针字段。它们天然引入 nil 风险，且序列化（如 JSON）时行为不一致（*string 为 nil 时默认不输出字段，而 string 字段输出空字符串）。
例如：
type Config struct {
TimeoutSec *int `json:"timeout_sec,omitempty"`
}
不如改为：
type Config struct {
TimeoutSec int `json:"timeout_sec,omitempty"`
}
- 如果真需表达“未配置”，加一个标记字段：
TimeoutSec int; HasTimeout bool - 或用指针 + 显式初始化：
cfg := &Config{TimeoutSec: new(int)}，但代价是每次访问都要if cfg.TimeoutSec != nil - 第三方库如
sql.NullString是特例：它封装了Valid字段来安全表达数据库 NULL，不是裸指针，应优先选用
测试中主动构造 nil 输入路径
很多 nil panic 在单元测试里根本跑不到，因为测试数据全是“理想值”。要覆盖边界，就得手动传 nil：比如测试一个接收 io.Reader 的函数，传 nil 看它是否 panic；测试接受 *http.Request 的 handler，用 httptest.NewRequest(...).WithContext(context.WithValue(nil, key, val)) 构造含 nil context 的请求。
- 对导出函数，文档应明确写出“panic if input is nil”或“accepts nil and returns early”，否则使用者无法预判
- 用静态检查工具如
staticcheck（检查SA5011：deref of nil pointer）能发现部分漏检，但它无法推断逻辑流，仍需人工覆盖 - 接口方法接收者为指针时（
func (r *Reader) Read(...)），调用var r *Reader; r.Read(...)会 panic —— 这类调用在测试中容易被忽略，因变量声明后常立刻初始化
