Go指针不会导致野指针或越界，因其禁用指针算术、默认nil初始化、逃逸分析防止栈变量地址逃逸、GC保障内存存活，且类型严格隔离；解引用前须显式判空。
为什么 Go 的指针不会导致野指针或指针算术越界
Go 语言从设计上就禁用了 C 风格的指针运算（比如 ptr++、ptr + 1），所有指针类型都严格绑定目标类型，*int 和 *string 完全不兼容。这直接堵死了多数内存越界和类型混淆漏洞。
编译器还强制要求：未初始化的指针默认为 nil，解引用前不做检查就会 panic；指针不能指向栈上已销毁的局部变量——因为逃逸分析会自动把可能被返回的局部变量挪到堆上。
-
&x只能取有效变量地址，不能对常量或表达式取址（如&(a + b)报错） - 没有指针类型转换（
unsafe.Pointer是特例，需显式导入unsafe包且不被常规代码推荐） - GC 保证只要还有活跃指针指向某块内存，就不会回收它
什么时候该传 *T 而不是 T
不是“能用指针就用”，而是看语义和开销是否匹配。传值（T）和传指针（*T）在 Go 中是两种明确的契约：
- 需要修改调用方原始数据时，必须用
*T（如func reset(x *int) { *x = 0 }） - 结构体大小超过 ~16 字节时，传
*T显著减少复制成本（可查go tool compile -gcflags="-l" main.go看是否内联） - 切片、map、channel 本身已是引用类型，通常无需再传其指针（
func f(s []int)已足够，func f(ps *[]int)多数是误用） - 小类型（
int、bool、string）传值更清晰、更安全，且无性能损失
nil 指针解引用 panic 的真实触发点
panic 不发生在声明或赋值时，而只在真正执行 *p 或 p.field 时才发生。很多人误以为“只要没写 *p = ... 就没事”，但其实读写都触发。
立即学习“go语言免费学习笔记（深入）”；
-
var p *int; fmt.Println(*p)→ panic -
var s *struct{ x int }; fmt.Println(s.x)→ panic（即使字段是导出的） - 接口值底层是
(type, data)，若data是nil指针，调用方法仍可能 panic（取决于方法是否检查 receiver） - 正确做法：始终在解引用前做
if p != nil判断，尤其在结构体嵌套、函数返回值、JSON 解析后字段可能为nil时
并发场景下指针共享的真实风险
指针本身是值类型，复制指针变量没问题；但多个 goroutine 同时读写指针所指向的同一块内存，就是典型的数据竞争——Go race detector 能捕获，但逻辑上必须由你控制。
- 不要靠“只读”假设：哪怕你认为某个
*Config只读，只要没加sync.RWMutex或用atomic.Value封装，就无法阻止别人并发修改 - map、slice 底层包含指针字段（如
array、buckets），所以map[string]*T共享时，不仅要保护 map 本身，还要保护每个*T的内容 - 最简方案：要么用
sync.Mutex保护整个数据结构，要么用不可变对象 + 每次替换指针（atomic.StorePointer）
指针的安全边界不在语法层面，而在生命周期和所有权约定——编译器帮你挡住了低级错误，但谁该释放、谁可修改、何时失效，这些得靠人来定。
