提前发现 nil 指针解引用需：方法开头加 nil 判断、返回指针时明确文档说明、调用方主动检查、用 go vet 辅助分析、单元测试覆盖 nil 输入场景。
nil 指针解引用 panic 怎么提前发现
Go 中最常遇到的指针错误就是对 nil 指针调用方法或访问字段，直接触发 panic: runtime error: invalid memory address or nil pointer dereference。它往往在运行时才暴露，尤其容易藏在嵌套结构体、接口转换或函数返回值里。
关键不是“怎么捕获 panic”，而是“怎么让 nil 无处遁形”：
- 所有接收者为指针的方法，开头加
if p == nil { return ... }判断（尤其当该方法可能被外部传入 nil 调用） - 从函数返回指针时，明确文档或注释是否可能返回
nil；调用方必须主动检查，别依赖“应该不会是 nil” - 用
go vet检查未使用的变量、无效果的赋值——它虽不报 nil 解引用，但能揪出明显可疑的指针链（比如p.x.y.z前没检查p） - 单元测试要覆盖
nil输入场景，例如传(*MyStruct)(nil)给方法，看是否 panic 或返回合理错误
什么时候该用 *T，什么时候该用 T
不是“想改原值就用指针”这么简单。核心判断依据是：值拷贝成本 + 是否真需要共享状态。
常见误判点：
立即学习“go语言免费学习笔记（深入）”；
-
struct很小（比如只有 1–2 个 int/bool）却总传*T：没收益，还增加 nil 风险和 GC 压力 -
struct很大（含 slice/map/chan 或嵌套深）却传T：每次调用都复制整块内存，性能掉得明显 - 方法集不一致：
func (t T) M()和func (t *T) M()属于不同方法集；实现接口时，若接口方法签名是(*T).M，你就不能用T类型变量去赋值 - map/slice/chan 本身是指针包装类型，传
T也能修改底层数组，没必要额外加*
sync.Pool 里存 *T 容易踩什么坑
用 sync.Pool 复用指针对象（如 *bytes.Buffer）很常见，但池中对象可能被任意 goroutine 重用，而指针指向的数据没被清空，导致脏数据泄漏。
典型表现：前一个请求写入的 JSON 字段，在下一个请求响应里意外出现。
- 每次从
Pool.Get()拿到*T后，必须显式重置内部状态（比如buf.Reset()、myObj.field = zeroValue） - 不要在
sync.Pool.New函数里返回带初始数据的*T，New 只负责构造干净实例，初始化逻辑必须放在 Get 之后 - 避免在 Pool 里存含闭包或引用外部变量的指针——这些引用可能已失效，引发不可预测行为
- 注意 GC：Pool 中的对象不保证存活，也不保证复用频率，别把它当长期缓存用
interface{} 里藏指针怎么安全取出来
把 *T 赋给 interface{} 很自然，但反向断言时容易忽略底层值是否为 nil 指针。
例如：var i interface{} = (*MyStruct)(nil)，此时 i != nil（因为 interface 本身非空），但 i.(*MyStruct) 会得到 nil，不是 panic，但后续解引用就崩了。
- 断言后立刻检查是否为
nil：if p, ok := i.(*MyStruct); ok && p != nil { ... } - 优先用类型断言 + ok 模式，别用强制断言（
i.(*MyStruct)），后者在类型不匹配时 panic - 如果业务逻辑允许
nil指针进入 interface，那所有消费方都得按 “interface 非空 ≠ 指针非空” 来写，这很反直觉，建议从源头约束输入
指针真正的复杂点不在语法，而在所有权边界模糊时没人知道谁该清空、谁该检查、谁该负责生命周期。写完一行 *p，多问一句：这个 p 是谁造的？上一次被谁改过？现在到底是不是安全的？
