go指针不支持算术运算，天然规避野指针，但nil解引用和逻辑悬空仍需防范；关键在明确生命周期、主动判空、控制共享，并通过panic机制、逃逸分析、-race检测等保障安全。
Go 的指针本身不支持算术运算，也没有裸内存操作，天然规避了 C/c++ 中典型的“野指针”问题。但 nil 指针解引用 和 逻辑上的悬空引用 仍是常见隐患。安全使用的关键不是回避指针，而是明确生命周期、主动判空、控制共享。
理解 nil 指针的 panic 行为
Go 访问 nil 指针不会导致内存破坏或静默错误，而是立即 panic —— 这是设计上的安全机制。但它不是“可忽略的警告”，而是必须处理的运行时错误。
- 函数接收指针参数时，应在首行检查是否为 nil，再访问字段或调用方法
- 结构体指针接收者方法中，若内部需读取字段，必须显式判空（即使 Go 允许 nil 接收者调用）
- 接口变量可能包装了 nil 指针，此时
i == nil为 false，需用reflect.ValueOf(i).IsNil()判断
避免逻辑野指针：生命周期比地址更重要
Go 有 GC，不会出现传统意义的“释放后使用”，但仍有“语义上已失效”的引用，比如：
- 返回局部变量地址（虽逃逸分析常自动转堆，但语义上易误解为栈变量）
- 在切片或 map 中长期保存大对象指针，阻止 GC 回收，造成内存滞留
- goroutine 中捕获了局部指针，但原作用域已结束，数据虽未被回收，但业务逻辑上已“过期”
建议用 go build -gcflags="-m" 查看变量逃逸情况，辅助判断语义合理性。
立即学习“go语言免费学习笔记（深入）”；
安全解引用与赋值的实用习惯
每次准备写 *p 或 p.x 前，都应默认多一步确认。
- 解引用前统一判空：
if p != nil { use(*p) } - 封装泛型安全解引用函数：
func Deref[T any](p *T, def T) T { if p == nil { return def }; return *p } - 赋值前确保指针有效：用
new(T)或&v初始化，而非声明后直接*p = x - 全局/长生命周期指针用完及时置
nil，尤其缓存、配置、连接句柄等场景
并发环境下的指针安全底线
指针本身不是并发问题根源，它指向的数据才是。多个 goroutine 同时读写同一块内存，就会触发 data race。
- 优先用 channel 传递指针所有权，而非共享指针
- 必须共享时，用
sync.Mutex保护整个结构体，或用atomic.Value安全替换指针值 - 避免在 map/slice 中存指针并由多个 goroutine 并发修改其指向的内容
- 启用
-race编译检测，这是最直接有效的防护手段