指针并发安全需分场景：①共享指针须加锁或用atomic（仅限指针值本身）；②避免捕获局部变量地址致悬垂指针；③sync.Pool中指针对象须重置状态；④channel传指针后所有权和线程安全责任转移给接收方。
共享指针变量未加锁导致数据竞争
多个 goroutine 同时读写同一个 *int、*sync.Mutex 或自定义结构体指针的字段时，Go 的 race detector 会报出 Data Race。这不是“指针本身不安全”，而是指针指向的内存被并发修改且无同步机制。
- 常见错误：把
var p *int声明在全局或传入多个 goroutine 后直接*p = 42 - 正确做法：用
sync.Mutex保护解引用和赋值操作，或改用sync/atomic（仅限基础类型如*int32、*uint64） - 注意：
atomic.StorePointer和atomic.LoadPointer操作的是指针值本身（即地址），不是它指向的数据；要原子更新指向内容，仍需锁或 CAS 循环
goroutine 捕获局部指针变量引发悬垂指针风险
当 goroutine 异步使用函数内局部变量的地址（比如 &x），而该函数已返回，栈上内存可能已被复用，导致读到脏数据或 panic。
- 典型场景：循环中启动 goroutine 并传入
&v，但v是循环变量，所有 goroutine 实际共享同一地址 - 修复方式：在循环体内显式创建新变量，例如
val := v; go func() { fmt.Println(*val) }() - 编译器不会报错，但
go run -race可能捕获部分情况；更稳妥的是避免传递局部变量地址给异步逻辑
sync.Pool 中存放指针对象的生命周期陷阱
sync.Pool 会缓存对象供复用，但如果存入的是指针（如 *bytes.Buffer），需确保其指向的底层数据不残留跨 goroutine 的状态或敏感信息。
- 问题：从 Pool 获取的
*bytes.Buffer可能含有之前使用者写入的旧数据，直接b.Write()可能拼接脏内容 - 必须在
Put前重置状态，例如调用b.Reset()；若结构体无 Reset 方法，应手动清空字段 - 禁止将含闭包、channel 或活跃 timer 的指针放入 Pool —— 它们可能在下次 Get 时已失效或引发 panic
channel 传递指针时的线程安全责任转移
通过 channel 发送指针（如 ch ）本身是安全的，但接收方获得指针后，是否可并发访问其指向的数据，完全由业务逻辑约定，Go 不做约束。
立即学习“go语言免费学习笔记（深入）”；
- 误用：发送
*User到 channel，多个 goroutine 接收后同时修改u.Name，无锁即竞争 - 推荐模式：channel 传递只读语义的指针，并在文档或命名中明确（如
type UserView *User）；或传递副本（ch ）避免歧义 - 性能权衡：小结构体拷贝开销低，比维护指针同步逻辑更可靠；大对象才值得传指针，但务必配套同步方案
并发中指针最棘手的不是语法或运行时限制，而是“谁拥有修改权”这个隐含契约容易被忽略。一旦多个 goroutine 认为自己可以自由写入同一块内存，bug 就藏在偶发的调度顺序里。
