nil指针调用*T方法必panic，因调用时隐式解引用；预防关键是解引用前显式判空，尤其函数返回、HTTP响应、接口断言等场景。
直接结论：nil 指针调用方法或访问字段必然 panic，预防核心不是“不传 nil”，而是“解引用前必须显式判空”——尤其在函数返回指针、HTTP 响应、接口断言等高频场景下。
为什么 *T 方法接收者遇到 nil 就 panic
Go 在调用 func (u *User) Name() 时，会隐式执行 *u 解引用。哪怕方法体里只写 return ""，只要签名是 *T 接收者，运行时仍会尝试解引用 u。一旦 u == nil，立刻触发 invalid memory address or nil pointer dereference。
常见误判是以为“方法没读字段就安全”，但这是错的。唯一例外是极少数标准库函数（如 fmt.Stringer.String() 的某些实现），但绝不能依赖。
- 结构体值接收者（
func (u User) Name()）可安全接受 nil 指针传入（因为传的是副本，不会解引用原指针） - 接口变量值为
(*User, nil)时，i.(User)会 panic，i.(*User)得到 nil 但不 panic —— 但后续再调.Name()仍 panic - 切片、map、channel 本身可 nil 且
len()/make()等操作安全，但结构体指针不行
HTTP 客户端中 resp.Body.Close() 触发 panic 的典型路径
错误写法：defer resp.Body.Close() 放在 if err != nil 判断之前，是高危模式。因为 http.Do() 失败时 resp 为 nil，defer 仍会执行，导致 nil.Body.Close() panic。
立即学习“go语言免费学习笔记（深入）”；
- 正确顺序永远是：先
if err != nil { return }，再defer resp.Body.Close() - 更稳妥写法：
if resp != nil { defer resp.Body.Close() }，作为双重防护（虽在逻辑正确时冗余，但防逻辑漏判） - 不要复用未检查的
resp：比如json.NewDecoder(resp.Body)前也必须确认resp != nil
工厂函数和返回值初始化能减少 nil 泄露
让函数自身控制返回值安全性，比靠调用方处处判空更可靠。
- 避免裸写
func NewUser() *User { return nil }，改为func NewUser() *User { return &User{} } - 若业务上确实需要表示“无用户”，优先返回
User{}零值 +Valid bool字段，而非nil指针 - 对 API 封装函数（如
GetUser(id int) (*User, error)），文档需明确：error 非 nil 时，*User 必为 nil；反之，*User 非 nil 时 error 必为 nil —— 这样调用方才敢做单边判断
接口断言和类型检查时的 nil 陷阱
接口变量 i 为 nil，仅当其底层类型和值都为 nil 时，i == nil 才成立。但 var u *User; i = u 后，i != nil（因类型是 *User），此时 i.(*User) 返回 nil，但再调方法仍 panic。
- 安全断言后务必判空：
if u, ok := i.(*User); ok && u != nil { u.Name() } - 不用
reflect.ValueOf(i).IsNil()做运行时判断——性能差且仅适用于指针/func/map/slice，业务代码中应靠设计规避 - 对可能为 nil 的接口，定义方法时统一用值接收者，或在方法开头加
if u == nil { return "" }
最易被忽略的一点：panic 不发生在赋值时，而发生在第一次解引用瞬间。一个 *User 变量从声明到传参全程为 nil 都没事，直到你写 user.Name 或 user.Save() 才崩。所以防御点必须卡在那个“点”之前，而不是幻想“不让它变成 nil”。
