直接用 chan *LogEntry 会丢日志或卡死，因缺乏背压控制、未强制刷盘、未隔离序列化逻辑，导致错行、末尾日志丢失、高QPS下阻塞甚至OOM。
为什么直接用 chan *LogEntry 会丢日志或卡死
因为没做背压控制、没强制刷盘、也没隔离序列化逻辑。压测时常见现象是：日志错行、进程退出前最后几条消失、高 QPS 下 logChan 持续阻塞甚至触发 OOM。
-
chan满后若只加default分支丢弃，ERROR 级别日志就真的没了 - 多个 goroutine 并发调用
json.Marshal或拼接字符串，共享同一内存区域，格式直接错乱 - 哪怕用了
bufio.Writer，底层仍是同步write(2)系统调用，机械盘或高延迟 NVMe 上毛刺照旧
RingBuffer 替代 chan 的真实价值在哪
不是为了炫技，而是解决两个硬约束：生产者不能等消费者，消费者必须按顺序、无锁地拿到完整日志块。
- 它是 SPSC（单生产者 / 单消费者）模型，天然无锁；
chan在多写场景下需调度或加锁，开销不可忽略 - 支持
Peek()和AddReadPosition()，可先检查日志协议完整性（比如 header-length 是否齐备），再移动读指针——这对自定义二进制审计日志至关重要 - 内存复用 + 固定大小分配，避免 GC 扫描压力；而
chan string每次写入都触发堆分配
如何用 RingBuffer 实现零拷贝批量落盘
“零拷贝”在这里不是指不 memcpy，而是避免跨 goroutine 复制日志内容。关键在格式化发生在生产者线程栈上，并把完整字节切片交由刷盘 goroutine 提交。
- 生产者端提前分配好固定大小的
[]byte缓冲区，在栈上完成时间戳、级别、消息的拼接，再把该切片“移交”给 RingBuffer - 消费者 goroutine 从 RingBuffer 中
Peek()出连续日志块，一次性提交给file.Write()，避免逐条 write - 搭配
file.Sync()控制落盘时机（仅 ERROR / AUDIT 级别强制），避免每条都 sync 导致 I/O 雪崩
容易被忽略的三个落地细节
RingBuffer 再好，漏掉这三点照样丢日志、卡主线程、OOM。
- 进程退出前必须显式调用
ringBuffer.Flush()+file.Sync()，否则缓冲区里最后一批日志永远不落盘 - RingBuffer 容量必须设上限（如 64KB ~ 1MB），且要配合背压策略（比如
TryEnqueue()失败时降级打点或 panic），否则突发流量直接吃光内存 - 日志格式化不能依赖
fmt.Sprintf或json.Marshal，它们逃逸到堆且分配不可控；应手写 ASCII 格式化逻辑，或用sync.Pool复用bytes.Buffer
