sync/atomic atomic.Uint64 与普通 uint64 混用有什么风险

在 Go 并发统计器中，atomic.Uint64 和普通 uint64 不是两种可以随意互换的写法。最稳妥的做法是：同一个共享计数值只选一种表示，并让所有读写都遵守同一套访问协议。若选择 atomic.Uint64，就用它的 Add、Load、Store 等方法；若保留普通 uint64，则必须由互斥锁保护，或统一使用针对该地址的原子函数，不能再夹杂直接读写。

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

• 类型层面：atomic.Uint64 是带方法和生命周期约束的原子类型，不能当作 uint64 直接赋值。
• 访问层面：原子读写与普通读写访问同一块存储，会破坏并发协议并触发数据竞争。
• 布局层面：atomic.Uint64 自动处理 64 位原子值的对齐；手写普通字段并调用旧式原子函数时要单独考虑 32 位平台。

先把两种表示放进一个小统计器

假设要做一个只记录请求总数和最近一次批次号的小对象。总数会被多个 goroutine 更新，批次号只在单线程切换阶段更新。两者应该在结构体中明确分开，不能因为它们都是无符号整数，就让调用方用同一种方式访问。

package counter

import "sync/atomic"

// Stats 只把并发共享的请求数声明为原子类型。
// BatchID 是普通字段，调用方需要在外部同步后再访问它。
type Stats struct {
	Requests atomic.Uint64
	BatchID  uint64
}

// RecordRequest 用方法访问原子字段，不暴露底层地址给调用方。
func (s *Stats) RecordRequest() uint64 {
	return s.Requests.Add(1)
}

// RequestsSnapshot 返回一个原子读取结果，避免直接读取 atomic.Uint64。
func (s *Stats) RequestsSnapshot() uint64 {
	return s.Requests.Load()
}

这里的两个字段可以同时存在，但“同时存在”不等于“可以混用”。Requests 的类型检查会阻止把它直接当成 uint64 使用；这个限制反而帮助审查者看出哪些代码必须经过原子方法。

真正危险的是同一存储上的访问方式混杂

如果一个普通 uint64 只由一个 goroutine 访问，它本身没有因为“旁边有 atomic.Uint64”就变得危险。问题发生在同一块内存被并发地用两套规则访问：一边调用 atomic.LoadUint64 或 atomic.StoreUint64，另一边却直接使用 x++、return x 或赋值。

package counter

import "sync/atomic"

// LegacyCounter 选择旧式原子函数时，所有访问都必须继续走原子函数。
type LegacyCounter struct {
	value uint64
}

// Add 以原子方式更新同一个普通 uint64 存储。
func (c *LegacyCounter) Add() uint64 {
	return atomic.AddUint64(&c.value, 1)
}

// Load 也必须保持原子访问，不能改成直接 return c.value。
func (c *LegacyCounter) Load() uint64 {
	return atomic.LoadUint64(&c.value)
}

这段代码里的字段类型虽然是普通 uint64，但它已经被纳入“所有访问走原子函数”的协议。不能再给它增加一个并发执行的 c.value++，也不能在其他方法中直接读取它。更推荐的新代码使用 atomic.Uint64，让访问入口更明显。

另一类错误是用 unsafe 把 atomic.Uint64 的内部存储伪装成普通整数。这会绕过类型边界和“首次使用后不可复制”的约束，维护成本高，也让数据竞争难以从代码表面发现。

32 位平台要特别看对齐和复制

Go 官方文档说明，atomic.Uint64 会自动处理 64 位原子值的对齐；而在 ARM、386 和 32 位 MIPS 上，使用旧式原子函数访问普通 64 位字段时，对齐责任在调用方。把一个普通 uint64 随手放到复合结构的中间位置，再直接交给 atomic.LoadUint64，就需要重新确认布局是否满足目标平台要求。

另外，atomic.Uint64 在第一次使用后不能复制。常见踩坑包括按值传递包含它的结构体、给结构体做值接收者方法，或把已使用的对象放入会复制元素的容器。应优先使用指针传递，并让方法接收者保持指针形式。

package counter

import "sync/atomic"

// SnapshotReader 用指针接收者，避免复制已经使用过的 atomic.Uint64。
type SnapshotReader struct {
	Total atomic.Uint64
}

// Read 只读取当前原子快照，不复制整个 SnapshotReader。
func (s *SnapshotReader) Read() uint64 {
	return s.Total.Load()
}

代码审查时用这张清单收口

遇到 atomic.Uint64 和普通 uint64 并存的代码，可以按下面顺序判断：

1. 它们是不是两个不同字段？如果是，分别确认各自的并发保护，不要因为类型相同就共用访问方式。
2. 如果指向同一计数，是否所有访问都使用同一套原子方法或同一把锁？只要出现直接读写，就需要重新设计。
3. 是否通过 unsafe、反射或按值传参绕过了原子类型？一旦绕过，优先改回指针和显式方法。
4. 是否支持 32 位构建？使用 atomic.Uint64 可减少手动对齐负担；旧式原子函数则要检查字段布局。

最终原则很简单：普通 uint64 可以是数据类型，atomic.Uint64 是数据类型加访问协议。它们可以在同一个项目中共存，但不要把同一个共享值在两套协议之间来回切换。

常见问题

atomic.Uint64 能直接转换成 uint64 吗？

不能把它当作普通整数直接转换或赋值。需要数值时调用 Load()，需要更新时调用 Add()、Store() 或其他对应方法。

普通 uint64 用 atomic.LoadUint64 后，还能直接读取吗？

如果该字段会并发访问，就不能混用直接读取。要么所有访问都采用原子函数，要么改成由锁保护的普通字段。

为什么推荐新代码使用 atomic.Uint64？

它把原子操作绑定在字段类型上，方法名更直观，并且官方类型会自动处理 64 位原子值的对齐约束；这不能替代并发设计，但能减少低层地址操作。