Go中指针本身不并发安全，需保护被指针访问的底层数据；多goroutine读写同一变量须用锁、原子操作或channel；atomic.Value适合写少读多的指针发布场景。
Go 中指针本身不是并发安全的
Go 的指针（
）只是内存地址的值，它不自带同步语义。多个 goroutine 同时读写同一个
指向的变量，或同时修改指针本身的值（比如
），都属于数据竞争——Go 的 race detector 会报
。
真正需要保护的是「被指针访问的底层数据」，而不是指针变量本身（除非你也在并发更新指针值）。常见误判是以为“用了指针就天然支持并发”，其实只是把共享变得更隐蔽了。
如果多个 goroutine 只读
指向的数据，且该数据初始化后不再修改（即不可变），则无需同步
只要有一个 goroutine 写该数据，所有读写操作都必须加锁（
）、用原子操作（
等），或通过 channel 传递所有权
避免在闭包中捕获可变指针变量并启动 goroutine，例如
—— 这里所有 goroutine 共享最后一个
的地址
用
安全地更新指针指向的基础类型
对于
、
、
这类固定大小的基础类型指针，Go 提供了原子操作支持。注意：原子操作只适用于指针所指向的值是机器字长对齐的整数或指针类型，不能用于
或
。
典型场景是状态标志或计数器：
立即学习
“
go语言免费学习笔记（深入）
”；
Git
程序猿必备版本控制工具
下载
更通用：可安全存取任意类型（包括
），但每次
都是整体替换，不支持字段级更新
不要对
（非 int32/int64）用原子操作——它在 32 位系统上可能不是原子的
原子操作不提供内存屏障外的同步语义；若需配合其他变量一起生效，仍要考虑 happens-before 关系
用
安全地发布指针引用
当需要在运行时动态切换一个全局配置指针（如
），又不想加锁阻塞读，
是标准解法。它保证写入和读取都是原子的，且读到的一定是某次完整
的结果。
返回
，必须显式类型断言，断言失败会 panic，所以确保只存一种类型
适合「写少读多」场景；频繁写入会增加 GC 压力（旧值等待回收）
它不阻止你修改
内部字段——若结构体本身可变，仍需额外
同步机制
（如字段加 mutex 或只存不可变副本）
避免在 channel 传输中意外共享指针数据
通过 channel 发送指针（如
）很常见，但容易忽略：接收方拿到指针后，若直接修改其指向内容，就可能与发送方或其他接收方产生竞争。
推荐做法是：channel 只传值类型（
），或传不可变指针（
不合法，但可用
模拟）
若必须传指针，应在文档或接口契约中明确「接收方不得修改」，或在发送前 deep copy（用
等工具）
特别警惕
：往通过 channel 收到的
所指向切片追加元素，会修改原底层数组，导致多个 goroutine 无意共享同一块内存
指针在并发中最难缠的不是语法，而是共享意图是否清晰——一旦开始用指针，就得立刻回答：谁负责生命周期？谁允许修改？有没有隐式别名？这些问题没想清，加再多锁也没用。
*T*intp = &xdata race on variable*Tsync.Mutexatomic.StoreInt32for _, p := range ptrs { go func() { *p = 1 }() }psync/atomic*int32*uint64*unsafe.Pointer*string*struct{}var state int32
// 安全写
atomic.StoreInt32(&state, 1)
// 安全读
v := atomic.LoadInt32(&state)
atomic.Value*MyStructStore*intatomic.Value*Configatomic.ValueStorevar config atomic.Value // 存 *Config
func SetConfig(c *Config) {
config.Store(c)
}
func GetConfig() *Config {
return config.Load().(*Config)
}
Load()interface{}*Configchan *Taskchan Taskchan *const Taskstruct{ data []byte } + copygithub.com/jinzhu/copierappend*[]int