Go指针本身并发安全，但共享指针指向的数据会引发竞态；需在多goroutine可能同时非原子写或读写共存时用mutex保护，注意生命周期与race detector的合理使用。
Go语言中指针本身不破坏并发安全，但共享指针指向的数据会
指针只是存储地址的变量，它自身是值类型，拷贝指针不会导致数据竞争。真正引发并发问题的是多个 goroutine 同时读写 指针所指向的同一块内存。比如两个 goroutine 都在修改 *p 指向的结构体字段，而没加同步机制，这就典型触发 data race。
常见错误场景：
- 把一个结构体指针传给多个 goroutine，各 goroutine 直接修改其字段（如
user.Name = "xxx"） - 用
sync.Pool放回含未清空状态的指针对象，下次取出后被误用 - 在
http.HandlerFunc中把请求上下文里的指针（如*DB）直接传给子 goroutine 并发操作
什么时候该用 mutex 保护指针指向的数据
只要存在「多 goroutine 可能同时写」+「写操作不是原子的」这两个条件，就必须加锁。注意：即使只读不写，若写操作正在发生，也可能读到中间态（比如结构体字段部分更新），所以读写都应受同一把锁保护。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 优先封装为方法，把锁逻辑收进结构体内部，例如
func (u *User) SetName(name string) { u.mu.Lock(); defer u.mu.Unlock(); u.name = name } - 避免对整个 map/slice 指针加锁，改用
sync.Map或分段锁（sharded lock）提升并发吞吐 - 不要在锁内做耗时操作（如 HTTP 调用、数据库查询），否则阻塞其他 goroutine
channel 传指针比传值更高效，但需警惕生命周期问题
用 channel 传递 *T 而非 T 可避免大对象拷贝，性能更好。但必须确保指针指向的数据在接收方使用时仍有效——这是 Go 并发中最容易被忽略的内存安全陷阱。
典型踩坑点：
- 在循环中取局部变量地址（
&item）并发送到 channel，循环下一次迭代就覆盖了该栈空间，接收方拿到的是悬垂指针 - 函数返回前启动 goroutine 并传入局部指针，函数返回后栈帧销毁，指针失效
- 从
sync.Pool获取对象后，未重置内部指针字段，导致旧数据残留并被并发访问
race detector 能发现大部分指针相关的并发问题
Go 自带的 go run -race 或 go test -race 是最有效的兜底手段。它能捕获对同一内存地址的非同步读写，无论该地址是通过指针、slice、map 还是全局变量访问的。
使用时注意：
- 必须在测试或开发阶段开启，生产环境不开（有约 2–5 倍性能开销）
- 它无法检测逻辑错误（如“本该加锁却忘了”但恰好没触发竞争），只能捕获实际发生的竞态事件
- 如果程序用
unsafe.Pointer或反射绕过类型系统，race detector 可能漏报
