根本原因是未做背压控制、未强制刷新缓冲区、未处理异常退出。chan满后若无default分支则阻塞，进程退出前未flush导致日志丢失，高qps时缓冲区溢出引发oom。
为什么直接用 chan *LogEntry 会丢日志或卡死
常见做法是开个带缓冲的 chan *LogEntry，后台起一个 goroutine 消费写文件。但实际压测时容易出现：日志错行、进程退出前最后几条消失、QPS 高时 channel 持续阻塞甚至 OOM。
根本原因有三个：
- 没做背压控制：
chan满了之后，select { case logChan 虽能防阻塞，但 <code>default分支若只是丢弃，就等于放弃关键 ERROR 日志 - 多个 goroutine 并发序列化（如
json.Marshal）或拼接字符串，竞争同一内存区域，导致格式错乱 - 写文件仍调用
file.Write()这类同步系统调用，buffer 再大也挡不住内核 write 毛刺，尤其在机械盘或高延迟 NVMe 上
RingBuffer 替代 chan 的真实价值在哪
RingBuffer 不是为“看起来更酷”，而是解决两个硬约束：一是生产者不能等消费者，二是消费者必须按顺序、无锁地拿到完整日志块。
它和普通 channel 的关键差异：
-
RingBuffer是单生产者 / 单消费者模型（SPSC），天然无锁；而chan在多写场景下需加锁或 channel 自身调度开销 - 支持
Peek()和AddReadPosition()，允许先检查协议完整性再移动读指针——这对带 header-length 的二进制日志格式（如自定义审计日志）至关重要 - 内存复用 + 固定大小分配，避免 GC 扫描压力；而
chan string每次写入都触发堆分配
如何用 RingBuffer 实现零拷贝批量落盘
真正“零拷贝”不是指不 memcpy，而是避免跨 goroutine 复制日志内容。核心是让格式化发生在生产者线程栈上，并把完整字节切片直接交由刷盘 goroutine 提交。
实操要点：
- 每个日志 entry 预留固定头部（如 8 字节 magic + 4 字节 len），写入前用
atomic.AddUint64(&writePos, uint64(len))原子推进，确保写指针不越界 - 生产者使用
PeekBytes(0, '\n')判断是否凑够一条完整日志（适用于文本日志），或用Peek(0, 4)读 length 字段再判断后续是否齐备（适用于二进制协议） - 刷盘 goroutine 只做两件事：
writev(fd, iovecs...)批量提交，然后调用file.Sync()强制落盘；不参与任何格式化、拼接、JSON 序列化 - buffer 大小建议设为 64KB（
1 ），太小导致频繁切换失败，太大则单次 <code>writev可能阻塞毫秒级
容易被忽略的崩溃一致性陷阱
RingBuffer 落盘快，但系统崩溃时最后一块 buffer 极易丢失——因为 writev 成功只表示进了内核 buffer，不代表已写入磁盘扇区。
必须补全的三步：
- 打开文件时加
os.O_SYNC或后续显式调用file.Sync()，别依赖bufio.Writer.Flush()，它只刷到内核 - 每批日志落盘后，用
atomic.StoreUint64(&flushedPos, currentWritePos)记录已持久化的偏移，重启时从该位置恢复 - 避免在 RingBuffer 中存指针或接口类型；所有数据必须是值类型（如
[256]byte），否则崩溃后内存不可重建
最危险的错觉，是以为 buffer 大了、用了 RingBuffer、起了 goroutine，就等于“异步且可靠”。真正的可靠性藏在 flush 时机、sync 范围、以及重启时能否精准续传这三处细节里。
