Go 原子变量复制后为什么失去同步保证

Go 的原子变量并不会因为“被复制过来的值相同”就继续代表同一份并发状态。原子操作的同步保证绑定到具体内存位置；结构体复制后，原子字段也得到新的地址。原对象和副本上的 Load、Store、Add 仍各自是原子的，却已经在维护两份互不联动的状态。

sync/atomic 的 Bool、Int32、Int64、Uint32、Uint64、Uintptr、Pointer[T] 与 Value 都不应在首次使用后复制。最可靠的设计是让含原子字段的对象拥有稳定地址，并只通过指针传递。

官方文档：https://pkg.go.dev/sync/atomic

同步的是同一地址，不是相同数值

假设一个 atomic.Int64 已经保存了 10。把包含它的结构体赋给另一个变量时，10 会被复制过去，但后续原子操作的接收者地址不同：&original.n 和 ©.n 是两个位置。对 original 的 Add 不会自动出现在 copy 中。

Go 内存模型说明，如果原子操作 B 观察到原子操作 A 的效果，那么 A synchronizes before B；所有原子操作表现为某个顺序一致的次序。这里的关键是“观察到效果”。副本保存到另一处内存后，对新地址的 Load 不再读取原地址上的 Store 或 Add，自然无法依靠那条共享变量上的通信关系传递最新状态。

一个最小示例就能看到状态分叉

package main

import (
	"fmt"
	"sync/atomic"
)

type Stats struct {
	requests atomic.Int64
}

func main() {
	var primary Stats
	primary.requests.Store(10) // 首次使用后，primary 不应再被复制。

	snapshot := primary // 错误：复制了已经使用过的 atomic.Int64。

	primary.requests.Add(1)  // 只更新 primary 内部的地址。
	snapshot.requests.Add(5) // 只更新 snapshot 内部的另一个地址。

	// 两个结果分别是 11 和 15，说明副本不再共享计数。
	fmt.Println(primary.requests.Load(), snapshot.requests.Load())
}

这个例子没有证明“原子操作失效”。每次 Add 和 Load 对各自的字段仍是原子的；真正失效的是调用方以为两个对象代表同一个逻辑计数器。并发系统最危险的地方正是这种“局部正确、整体分叉”。

如果复制动作与其他 goroutine 正在写同一个原子对象同时发生，情况更糟：结构体赋值本身是普通内存复制，不是对整个原子对象的原子快照。官方契约直接禁止首次使用后复制，因此不应尝试推导某个具体实现下是否“碰巧可用”。

复制经常藏在 API 形状里

显式的 b := a 很容易发现，真正高频的错误反而来自值语义 API：

• 给含原子字段的结构体定义值接收者方法；每次调用都会得到接收者副本。
• 把该结构体作为普通参数按值传入函数，或从函数按值返回已经使用的对象。
• 使用 for _, item := range items 遍历结构体切片，item 是元素副本。
• 把对象作为 map 的值取出；map 取值本身得到副本，而且值通常不可寻址。
• 复制外层配置、服务或指标结构时，顺带复制嵌套的原子字段。

type Counter struct {
	value atomic.Int64
}

// 错误：值接收者会复制整个 Counter，包括已经使用的原子字段。
func (c Counter) IncWrong() {
	c.value.Add(1)
}

// 正确：指针接收者始终操作原对象中的同一地址。
func (c *Counter) Inc() {
	c.value.Add(1)
}

值接收者的错误尤其隐蔽：方法内部的 Add 确实成功了，但更新的是临时副本，方法返回后结果直接丢失。代码看起来“用了 atomic”，指标却始终不增长。

修复重点是稳定所有权

不要在每个调用点临时提醒“别复制”，而要让 API 本身更难复制。构造函数返回指针，方法使用指针接收者，集合保存 *Counter，就能让所有 goroutine 明确共享同一个实例。

package metrics

import "sync/atomic"

type Counter struct {
	value atomic.Int64
}

func NewCounter() *Counter {
	// 返回指针，让对象从创建开始就拥有稳定身份。
	return &Counter{}
}

func (c *Counter) Add(delta int64) int64 {
	// 所有调用都落到同一个 atomic.Int64 地址。
	return c.value.Add(delta)
}

func (c *Counter) Load() int64 {
	return c.value.Load()
}

type Registry struct {
	// 集合保存指针，避免取值时复制 Counter。
	counters map[string]*Counter
}

如果外层对象还有很多配置字段，可以把可复制配置与不可复制运行状态分开。配置使用值语义，运行时计数器、锁和连接池放在单独的指针对象中。这样复制配置不会顺带复制同步原语。

atomic.Pointer 和 atomic.Value 也有同样边界

atomic.Pointer[T] 的副本可能在复制瞬间指向同一个业务对象，但两个原子指针槽位仍是不同地址。之后对一个槽位 Store 新指针，另一个槽位不会更新。共享“所指对象”不等于共享“原子发布槽”。

atomic.Value 的文档同样明确：首次 Store 后不得复制。它内部维护一致类型的原子发布状态，复制后再分别 Store 会得到两条独立发布线；并发复制还可能破坏内部多字信息的一致观察。正确方案仍然是共享 *atomic.Value 所在的稳定外层对象，而不是复制 Value。

为什么类型里有 noCopy，编译器却没有报错

当前标准库的类型化原子值包含一个未导出的 noCopy 字段。它的 Lock 方法是提供给 go vet 的 copylocks 检查器识别的标记，不是运行时锁，也不会改变结构体赋值语法。换句话说，它能帮助静态检查发现风险，但不会让复制在编译阶段自动失败。

# 扫描当前模块中复制锁和原子类型等问题。
go vet ./...

# 如果项目较大，可先只检查目标包，缩短反馈时间。
go vet ./internal/metrics

工具提示通常会指向“按值传递”“赋值复制”或“range 变量复制”等位置。修复时应沿着类型的整个生命周期处理，而不是只在报警行前后做一次取地址；如果上游仍按值返回，下游依旧会拿到副本。

首次使用前可以复制吗

官方措辞是“不得在首次使用后复制”，因此尚未使用的零值在语义上可以被放入最终对象。不过工程上最好在最终存储位置直接构造，尤其不要把含原子字段的对象当普通值在多层 API 间传递。这样能避免以后有人在构造阶段提前 Store，悄悄把安全复制变成违规复制。

还要区分类型化原子值与旧式包级函数。对普通 int64 调用 atomic.AddInt64(&n, 1) 时，原子性同样绑定到 &n；复制 n 只会得到另一个普通整数位置。虽然它没有 noCopy 字段，复制后也不会继续共享计数，并发普通复制仍可能形成数据竞争。

排查清单

• 类型中是否包含 atomic.Int64、atomic.Bool、atomic.Pointer、atomic.Value 或其他同步原语？
• 是否存在值接收者、按值参数、按值返回或显式结构体赋值？
• 集合是否保存结构体值，并通过 range 变量或 map 取值操作它？
• 构造函数是否返回指针，所有方法是否稳定操作同一实例？
• go vet ./... 是否仍报告 copylocks？

结论

Go 原子变量复制后“失去同步保证”，准确地说是共享状态身份被复制成了两个地址。每个地址上的操作仍是原子的，但它们不再维护同一个逻辑变量；若复制与并发访问重叠，还违反了类型的使用契约。把含原子字段的对象设计成稳定指针身份，并用 go vet 检查复制边界，才是长期可靠的修复。

常见问题

复制后只读副本可以吗？

官方契约仍然不允许首次使用后复制。即使你只想做快照，也应通过 Load 读取普通值，再复制这个普通值，而不是复制原子容器本身。

把 atomic.Int64 放进切片一定错误吗？

如果切片元素从未使用就完成初始化，随后不再触发搬移，理论边界较窄且容易被后续修改破坏。工程上更稳妥的是保存指针，或先固定容量并确保元素在最终位置初始化；不要依赖隐含的“不再扩容”约定。

加一个互斥锁能修复副本分叉吗？

不能。如果锁也随结构体一起复制，原对象和副本会拥有不同锁。真正需要的是一个共享对象身份，锁或原子字段都放在这个对象里并通过指针访问。

技术依据：https://pkg.go.dev/sync/atomic、https://go.dev/src/sync/atomic/type.go、https://go.dev/ref/mem。