不一定。go允许nil指针调用指针接收器方法，只要不访问字段或调用其他指针方法；若解引用则panic，因此需在依赖字段前显式检查p==nil。
nil 指针调用方法会 panic 吗？
不一定。Go 允许 nil 指针调用带指针接收器的方法，只要方法内部不解引用该指针（即不访问 Struct 字段或调用其方法）。这是 Go 和其他语言很不同的地方，也是容易误判健壮性的关键点。
常见错误现象：panic: runtime Error: invalid memory address or nil pointer dereference，往往发生在你写了 p.field 或 p.Method() 但 p 是 nil 时。
- 如果方法只做类型判断、返回默认值、或仅调用非指针接收器的函数，
nil安全 - 一旦出现
if p == nil { return }这类防御逻辑，说明你已经意识到风险 —— 但别只写一半：漏掉后续所有对p的解引用才是真坑 - 接口变量持有一个
nil指针值时，仍视为“非 nil 接口”，这点常被忽略
什么时候必须显式检查 p == nil？
当方法逻辑依赖 receiver 的字段、嵌套结构、或需要调用其他指针接收器方法时，nil 检查不是可选项，是必选项。
使用场景：实现 Stringer、error、自定义容器的 len() 或 Get() 方法时，用户传入 nil 很常见。
立即学习“go语言免费学习笔记（深入）”；
- 检查位置要靠前，且覆盖所有可能解引用的路径（比如多个 if 分支、defer 中的调用）
- 不要只在开头 check 一次就认为万事大吉 —— 如果方法里又调了另一个指针接收器方法，它自己也得 check
- 避免用
reflect.ValueOf(p).IsNil()，开销大且没必要；直接if p == nil最清晰
示例：
func (p *User) Name() string { if p == nil { return "" } return p.name // 安全 }值接收器 vs 指针接收器：nil 安全性差异
值接收器方法永远收不到 nil —— 因为 Go 会先解引用再传值，nil 指针传给值接收器会导致立即 panic。所以值接收器天然“不处理 nil”，而指针接收器才承担这个责任。
- 如果你希望方法能安全应对
nil，必须用指针接收器 - 但反过来不成立：用了指针接收器 ≠ 自动
nil安全，只是给了你检查的机会 - 混用两种接收器易出错：比如
User.String()是值接收器，User.Save()是指针接收器，前者在nil时根本走不到
测试 nil 边界 case 的实际写法
不写测试，nil 健壮性就是纸上谈兵。重点不是“覆盖所有方法”，而是“每个可能暴露给用户的入口都测 nil”。
- 测试变量直接声明为
var u *User，而不是&User{}再置空 - 对导出方法（尤其是实现标准接口的）逐个验证：
fmt.sprint(u)、json.Marshal(u)、u.Error() - 注意 goroutine 场景：并发中某个字段被清空，receiver 变成逻辑上的
nil，但指针本身非空 —— 这类需额外状态检查，不是简单p == nil能覆盖
最容易被忽略的是：**方法签名看起来安全，但内部调用了第三方库或未导出 helper，而那个 helper 没做 nil 检查**。健壮性不在第一层，而在最深那一行解引用。