直接用 sync/atomic 是因环形缓冲区需低延迟高吞吐，chan 有调度开销，mutex 在竞争时阻塞 goroutine；原子操作控制读写指针可避免锁争用，但须保证单生产者/消费者，多生产者仍需 mutex，且缓冲区容量必须为 2 的幂。
为什么直接用 sync/atomic 而不用 chan 或 mutex
因为环形缓冲区（ring buffer）的核心诉求是低延迟和高吞吐，chan 有调度开销和内存分配，mutex 在竞争激烈时会阻塞 Goroutine；而无锁实现靠原子操作控制读写指针，避免锁争用。但注意：这不等于“完全无锁”——你仍需保证生产者/消费者单线程调用，否则原子操作无法覆盖数据竞争。
- 多个生产者？必须加
sync.Mutex保护写入逻辑，原子操作只管指针推进 - 缓冲区大小必须是 2 的幂（如 1024、4096），否则
mask位运算取模会出错 - Go 的
atomic.LoadUint64/atomic.CompareAndSwapUint64是唯一可信赖的跨平台原子指令，别用+=或++
RingBuffer 结构体里哪些字段必须是 uint64
只有读/写指针（readPos、writePos）和容量（cap）需要 uint64，且必须用 atomic 操作访问。其他字段如 data []byte 或 mask uint64（cap - 1）可为普通类型，但 mask 必须在初始化时一次性算好，不能每次 & 都重新计算 cap-1 —— 否则可能因 cap 变化导致越界。
- 错误写法：
pos & (b.cap - 1)→ 若b.cap不是常量或被并发修改，结果不可预测 - 正确写法：
pos & b.mask，其中b.mask = uint64(cap) - 1，且cap构造后不可变 - 读写指针用
uint64是为了防止溢出后符号位干扰，同时兼容atomic函数签名
如何安全判断缓冲区满或空，避开 ABA 问题
不能仅靠 writePos == readPos 判断空，也不能靠 writePos == readPos + cap 判断满——因为指针是不断累加的，要结合 mask 做相对偏移比较。标准做法是预留一个 slot（即实际可用容量为 cap - 1），用 (writePos - readPos) >= cap 判满，writePos == readPos 判空。这规避了 ABA：即使指针绕回，差值依然反映真实长度。
- 判空：
atomic.LoadUint64(&b.readPos) == atomic.LoadUint64(&b.writePos) - 判满：
atomic.LoadUint64(&b.writePos) - atomic.LoadUint64(&b.readPos) >= uint64(b.cap) - 注意减法不会溢出：Go 中无符号整数溢出是回绕，但这里我们依赖的是“逻辑差值”，只要
writePos ≥ readPos（单生产者前提下成立），结果就可信
写入时如何避免覆盖未读数据
写入前必须先检查是否满，但检查和写入之间存在竞态窗口。正确做法是：先原子读取当前 writePos 和 readPos，算出可写长度；若足够，再用 atomic.CompareAndSwapUint64 尝试推进 writePos；失败则重试。不要用两阶段提交式设计（比如先 CAS 写指针、再拷贝数据），因为数据拷贝本身不可逆。
- 关键代码片段：
for { r := atomic.LoadUint64(&b.readPos) w := atomic.LoadUint64(&b.writePos) if w-r - 每次只推进 1 字节？不现实。批量写入需按块做同样逻辑：先算起始位置和长度，CAS 推进整个长度，失败则回退并重试
- 如果业务允许丢数据，可跳过满检查直接写（覆盖最老数据），此时判满逻辑要改为
w - r >= uint64(b.cap)，留出 1 个 slot 缓冲
真正难的不是原子操作本身，而是把“指针推进”和“数据搬运”的边界对齐——稍有不慎，就会出现写了一半指针、另一半数据没落盘的情况。务必让所有数据拷贝完成后再执行最终的指针 CAS。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
