直接用 chan string 传日志会卡住，因 go runtime 的 chan 在高并发下锁争用严重；ringbuffer 容量必须是 2 的幂以保证位运算绕回正确；需用 atomic.compareandswapuint64 配合 atomic.loaduint64 实现无锁写入，避免覆盖；字符串写入前应复用 sync.pool 缓冲并避免逃逸。
为什么直接用 chan string 传日志会卡住 handler
不是逻辑写错了，是 Go runtime 的 chan 在 8+ goroutine 并发写入时就开始锁争用。每个 send 操作都要走 runtime.chansend，里面调用 runtime.lock，本质仍是互斥锁。高并发下 goroutine 排队、上下文切换、P99 延迟跳变——你看到的“卡”，其实是锁在等 CPU 时间片。
RingBuffer 容量必须是 2 的幂，否则位运算绕回就错
用 idx & (cap - 1) 替代 idx % cap 是为了硬件级常数时间 + 自动处理负溢出，但前提是 cap 是 2 的幂（如 1024、4096）。否则 idx & (cap - 1) 会把索引映射到错误位置，导致读写错位、数据覆盖或 panic。
- 构造时别接受任意
size：必须上取整到最近 2 的幂，例如size=1500 → cap=2048 - 不建议静默修正：应直接
panic(fmt.Sprintf("capacity %d not power of 2", cap)) - 别用
container/ring：它不是环形缓冲区，是链表，每次Next()都触发堆分配和指针跳转
atomic.CompareAndSwapUint64 必须配对 atomic.LoadUint64，不能只加不检
常见错误是写成 atomic.AddUint64(&rb.writeIndex, 1) —— 这会让多个 goroutine 同时推进到同一 slot，互相覆盖。正确流程是：
- 先
atomic.LoadUint64(&rb.readIndex)和atomic.LoadUint64(&rb.writeIndex) - 算长度：
length := writeIdx - readIdx，判断是否满（length >= cap） - 未满则尝试
atomic.CompareAndSwapUint64(&rb.writeIndex, oldWrite, newWrite)；失败就重试，不 fallback 到锁 - 数据写入必须在 CAS 成功后、更新 index 前完成，靠 Go 的 atomic 内存序保证可见性
字符串写入前要避免逃逸和重复分配
每次 Write(string) 都会隐式转 []byte，触发堆分配；若 RingBuffer 底层用局部 make([]byte, ...)，GC 可能提前回收长期持有的切片。
- 底层缓冲区必须一次性分配、绑定生命周期：
data := make([]byte, cap * slotSize) - 接收日志时优先复用
sync.Pool中的[]byte缓冲，copy进去再写入 - 若业务允许，直接序列化成二进制格式（含 header-length）写入，省掉
string → []byte转换 -
Read方法别返回跨边界的单个切片；应拆成headPart和tailPart，由调用方决定是否拼接
真正难的不是写几个原子操作，而是确保所有字段严格对齐、所有检查都在 CAS 前完成、所有写入都在 CAS 成功后立即发生——漏掉任一环，就会在高负载下出现静默数据错乱。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
