go中对nil指针调用带接收者的方法会panic，因其隐式解引用导致无效内存访问；接口值为nil指针时调用方法同样panic；安全做法是在方法开头显式检查nil并返回合适零值。
Go里nil指针调用方法为什么会panic
Go中对nil指针调用**带接收者的方法**，只要该方法内部访问了接收者字段或调用了其他需解引用的操作，就会触发panic: runtime error: invalid memory address or nil pointer dereference。这不是“未定义行为”，而是明确的运行时错误——因为Go在调用方法前会隐式解引用指针，而nil无法解引用。
常见误判是以为“方法没用到字段就安全”，但只要方法签名是func (p *T) Method()，Go就要求p非nil（除非方法体全程不碰p.*且不传给其他需非空的函数）。
- 接口变量值为
nil时，调用其方法也可能panic——取决于底层具体类型是否为nil指针 -
nil切片、map、channel可以安全调用内置操作（如len、append、range），但自定义结构体指针不行 - HTTP handler里常看到
if r == nil { return }，就是因为r.Context()等方法在r为nil时直接panic
如何写零值安全的方法（*T接收者）
核心原则：方法开头加nil检查，且返回有意义的结果（而非静默忽略）。不是所有方法都适合这么做，但对工具类、访问器、格式化类方法尤其必要。
比如一个User结构体，想安全获取用户名：
立即学习“go语言免费学习笔记（深入）”；
func (u *User) Name() string {
if u == nil {
return ""
}
return u.name
}
- 不要用
if u != nil { return u.name }然后缺省返回——Go要求所有分支有返回值，漏写会编译失败 - 返回零值要符合语义：
string返回""，int返回0，error返回nil，但bool慎返false（可能掩盖逻辑歧义） - 如果方法本意就是“必须有实例”，比如
Save()，那就不该容忍nil，直接让panic暴露问题更合适
接口值nil vs 指针值nil：容易混淆的两种nil
这是最常踩的坑：var u *User是nil指针；而var i interface{}赋值u后，i不是nil接口值——它包含(*User, nil)，即类型非空、值为空。此时i.(User)会panic，i.(*User)得到nil但不会panic，但再调用其方法仍panic。
- 判断接口是否真正“空”，不能只用
i == nil，得用reflect.ValueOf(i).IsNil()（仅适用于指针/func/map/slice等） - 更实用的做法：定义方法时统一用指针接收者，并在文档/注释里写明“此方法接受nil输入并返回零值”
- JSON反序列化时
json.Unmarshal([]byte(`null`), &u)会让u保持nil，后续直接调用u.Method()必panic
第三方库里的零值安全实践参考
标准库其实已有范例：time.Time.IsZero()接受nil receiver没问题，因为time.Time是值类型；但http.Request.URL是*url.URL，所以req.URL.String()在req.URL == nil时panic——这也是为什么官方示例总先判空。
-
strings.Builder的String()和Reset()都允许nilreceiver，返回""或静默处理 -
sync.Pool.Get()可能返回nil，使用者必须检查，不能假设“池子一定有值” - 用
golang.org/x/exp/slices时注意：所有函数参数都是值类型，不存在nil指针问题；但若你封装了*[]T，就得自己守规矩
真正的难点不在语法，而在判断“这个方法该不该容忍nil”——它取决于上下文语义，而不是技术能否实现。写完一个*T方法，停下来问一句：如果传进来的是nil，调用方是希望崩溃、静默、还是有明确fallback？答案不同，实现就不同。
