Go中必须检查指针是否为nil再解引用，否则会panic；应优先用值类型字段、JSON反序列化时谨慎处理指针、用OptionalString等封装有效性，并借助staticcheck等工具提前发现风险。
检查指针是否为 nil 再解引用
Go 中对 nil 指针解引用会直接 panic，错误信息类似 panic: runtime error: invalid memory address or nil pointer dereference。这不是运行时可恢复的错误，必须在解引用前主动判断。
常见场景包括：函数参数传入结构体指针、从 map 或 channel 获取指针值、调用方法前未确认接收者非空。
- 永远不要假设指针“应该不为
nil”——尤其是外部输入、JSON 反序列化结果（如json.Unmarshal对字段为*string时可能留nil） - 若逻辑上允许
nil，应在函数开头统一校验，例如：func processUser(u *User) error { if u == nil { return errors.New("user cannot be nil") } // 后续安全使用 u.Name, u.ID 等 } - 避免嵌套解引用，如
u.Profile.Address.City—— 应逐层检查或改用辅助函数封装
用结构体字段默认值替代裸指针字段
定义结构体时，优先使用值类型字段而非指针字段，除非明确需要区分“零值”和“未设置”。比如 *string 常被误用于表示“可选字符串”，但实际引入了 nil 风险。
更安全的做法是用值类型 + 显式标记字段是否有效：
立即学习“go语言免费学习笔记（深入）”；
- 用
string字段 + 单独的HasName bool标志位（适合简单场景） - 或使用自定义类型封装有效性，例如：
type OptionalString struct { Value string Valid bool } func (o OptionalString) String() string { if !o.Valid { return "" } return o.Value } - 第三方库如
github.com/guregu/null提供了null.String等类型，内部含Valid字段，比裸*string更可控
JSON 反序列化时谨慎处理指针字段
json.Unmarshal 对结构体中指针字段（如 *int、*string）的行为是：遇到 JSON null 或字段缺失时，保持该指针为 nil；遇到有效值则分配内存并赋值。这容易导致后续访问 panic。
- 如果 API 允许字段为
null，且业务逻辑需区分“未提供”和“显式设为 null”，才用指针字段；否则一律用值类型 - 对必须用指针的字段，反序列化后立即检查，或封装为方法：
func (u *User) Name() string { if u.Name == nil { return "" } return *u.Name } - 测试时务必覆盖 JSON 输入含
"name": null和字段完全缺失两种 case
启用静态检查工具提前发现潜在 nil 解引用
Go 编译器本身不检查指针是否为 nil，但可用工具辅助识别高风险路径。
-
staticcheck能检测部分明显未判空就解引用的模式（如局部变量赋值后立刻解引用但无判空） -
go vet对某些特定模式（如if p != nil { return *p }后续仍可能解引用）也有提示 - 更严格的方式是用
nilness分析器（已集成进golang.org/x/tools/go/analysis/passes/nilness），它基于数据流分析推断可能为nil的变量，但注意其存在误报，不宜直接阻断 CI - 关键服务中，建议在单元测试里故意传
nil指针，验证错误路径是否被正确捕获和返回，而不是 panic
