go中nil指针解引用会立即panic，必须显式判空；优先用值接收器规避风险，但大结构体需权衡性能；借助staticcheck、nilness和单元测试提前发现隐患。
Go 中 nil 指针解引用会直接 panic
Go 语言里对 nil 指针取值（比如 *p）或调用方法，会立即触发运行时 panic：panic: runtime error: invalid memory address or nil pointer dereference。这不是编译错误，而是在运行时崩溃——所以空指针检查不是“可选优化”，而是必须的防御动作。
所有指针字段/参数都应显式判空
尤其在结构体嵌套、函数入参、接口转型后得到的指针场景下，容易忽略隐式 nil。常见易漏点包括：
- 从 map 中取值后断言为指针类型：
v, ok := m["key"]; p, ok := v.(*MyStruct)—— 若v不存在或类型不匹配，p就是nil - json.Unmarshal 后未检查字段是否被填充（如字段是
*string，但 JSON 中该 key 缺失或为 null） - 数据库查询返回
*T，但查无结果时 ORM 可能返回nil（如 gorm 的First()）
正确做法是：只要变量类型是 *T，且来源不可信（非字面量、非明确初始化），一律先判 if p == nil 再使用。
用值接收器替代指针接收器能规避部分风险
如果方法逻辑不修改接收者，优先用值接收器（func (t T) Method()）。这样即使传入的是 nil 指针，也不会 panic —— 因为 Go 会自动解引用并拷贝值（前提是底层类型可复制）。但注意：
立即学习“go语言免费学习笔记（深入）”；
- 大结构体传值有性能开销，别盲目替换
- 若方法需要修改原值，则必须用指针接收器，此时判空不可省略
- 接口变量存储了
*T类型的方法集，调用时仍可能因nil指针 panic
借助工具提前发现潜在 nil 解引用
静态分析工具比人工更可靠：
-
staticcheck能识别形如if p != nil { return *p }这类冗余判空，也能发现明显缺失的判空路径 -
nilness（已归入go vet）专门检测控制流中可能的 nil 指针解引用 - 单元测试覆盖边界 case：手动构造
nil指针输入，验证是否 panic 或返回合理错误
真正难防的不是明面上的 *p，而是深层嵌套访问（如 p.Field1.SubField2.Name）——这种链式调用一旦中间某环是 nil，panic 位置离原始赋值点很远，调试成本高。宁可多写几行判空，也不要赌“这里不可能是 nil”。
