解引用 nil 指针会触发 panic：“invalid memory address or nil pointer dereference”；go 运行时在执行 *p 或 p.field 且 p 为 nil 时立即中止 goroutine，需显式判空（if p != nil）后才可安全解引用。
解引用 nil 指针会触发 panic: "invalid memory address or nil pointer dereference"
Go 运行时检测到对 nil 指针的解引用（即用 * 操作符读/写），会立即中止当前 goroutine 并抛出 panic。这不是编译错误，而是在运行期确定的——只要那行代码被执行，就一定崩。
- 常见错误现象：程序突然退出，堆栈里出现
panic: runtime error: invalid memory address or nil pointer dereference，紧接着是goroutine X [running]:和出问题的文件行号 - 典型场景包括：
var p *int; fmt.Println(*p)、if p != nil { *p = 42 }却漏了判空直接用了*p、结构体字段是指针但没初始化就访问其成员 - 注意：仅声明指针变量（如
var p *string）不 panic；只有真正执行*p或p.field（且p是nil）才会触发
如何安全地解引用指针
核心原则：解引用前必须确认指针非 nil。Go 不提供自动空值保护（比如像 Rust 的 Option 或 Swift 的可选链），全靠程序员显式检查。
- 最直接的方式是加
if p != nil判断，再在分支内解引用；不要写成if *p != ""这种跳过判空的操作 - 函数返回指针时（如
json.Unmarshal输出参数、http.NewRequest），务必检查是否为nil再用，尤其当输入数据可能为空或解析失败时 - 避免“防御性解引用”：比如
if p != nil && *p == "foo"是安全的；但*p == "foo" || p == nil是错的——Go 中逻辑或短路，但左操作数仍会先求值，*p依然 panic
struct 字段指针解引用的坑
嵌套结构体里含指针字段时，容易误以为外层非 nil 就代表内层也非 nil，其实完全独立。
- 例如：
type User struct{ Profile *Profile }; var u *User = &User{}，此时u非 nil，但u.Profile是nil；直接写u.Profile.Name就 panic - 不能依赖零值初始化：即使你写了
u := &User{Profile: &Profile{}}，如果后续某处把u.Profile设为nil，风险依旧存在 - 推荐做法：对深层字段解引用前逐级检查，或封装方法（如
u.ProfileName()）内部做判空，避免调用方重复写if u != nil && u.Profile != nil && u.Profile.Name != ""
调试和定位 nil 指针 panic 的实用技巧
panic 堆栈只显示崩溃点，但源头往往在更早的赋值或传参环节。
立即学习“go语言免费学习笔记（深入）”；
- 用
go run -gcflags="-l" ...关闭内联，能让堆栈更准确指向实际调用位置（尤其在函数传参时） - 在疑似出问题的指针变量附近加日志：
fmt.Printf("p=%v, p==nil? %t\n", p, p == nil)，比猜更快 - 启用
GO111MODULE=on+go vet可捕获部分明显问题（如未使用的指针接收者），但无法发现运行时才产生的 nil 解引用 - 测试时故意传
nil进函数，看是否 panic——这是验证判空逻辑是否覆盖到位的最简单方式
nil 指针解引用没有例外情况，也没有隐式转换兜底。它发生得干脆利落，但也意味着：只要你在所有解引用前加了一次 != nil 判断，就能彻底避开。难的不是语法，而是每次伸手去取值前，有没有条件反射般多想一下——这个指针，它真的被认真初始化过了吗？
