auditLogChan 缓冲大小应通过压测确定峰值日志量并乘以3–5倍设为基准，再加水位保护（如>80%时降级），避免过小丢日志或过大引发OOM；禁用无缓冲chan。
auditLogChan 缓冲大小怎么设才不丢日志又不爆内存
缓冲区不是越大越好。设太小（比如 10），高并发时 select 写入失败直接丢日志；设太大（比如 100000），突发流量把日志全塞进内存，GC 压力陡增，还可能 OOM。
- 先压测：模拟 2–3 倍日常 QPS，观察单秒最大日志条数，乘以 3–5 倍作为缓冲基准（例如峰值
800条/秒 → 缓冲设4096） - 加水位保护：写入前用
len(auditLogChan) > cap(auditLogChan)*0.8判断是否快满，超阈值则降级为同步写或丢弃非关键字段（如userAgent） - 绝对别用
make(chan *AuditLog, 0)（无缓冲），主流程会卡在auditLogChan 上，等消费者取走才继续
消费者 goroutine panic 后如何保证日志不积压丢失
只起一个 go writeAuditLoop() 是常见错误——它 panic 了，后续所有日志就积在 channel 里，程序退出时全丢。
- 用
recover包裹循环体，捕获 panic 后打错、重连文件/ES、再continue，别让 goroutine 退出 - 每次从
取日志必须加超时：用 <code>select+time.After(5 * time.Second)，防 channel 长期阻塞导致整个消费者僵死 - 进程退出前，用
sync.WaitGroup等待当前正在写的日志落盘，但加 2 秒 timeout，避免无限等待
文件写入后为什么还会丢数据？关键在 Close() 和 Sync()
os.File.Write 是带缓冲的系统调用，数据先写入内核缓冲区，再异步刷入磁盘；而 f.Close() 不仅释放文件描述符，还会触发内核将剩余缓冲数据落盘。
- 必须在
os.OpenFile成功后立即用defer f.Close()，确保无论函数如何返回（正常、panic 或提前return），Close()都会被执行 - 审计/ERROR 级别日志必须显式调用
f.Sync()，否则仅Close()无法保证落盘（尤其在 ext4/xfs 上，Close()不强制 flush 到磁盘） - 别依赖
ioutil.WriteFile：它内部虽有Close()，但若程序在f.Write(data)后、首次f.Close()前崩溃（如被SIGKILL终止），缓冲区数据就丢了
批量写入时怎么避免行粘连、错乱和性能毛刺
直接用多个 goroutine 并发 file.WriteString() 或无缓冲 chan string，会导致日志错乱、进程退出丢日志、磁盘卡顿时 channel 堵死。
立即学习“go语言免费学习笔记（深入）”；
- 必须用单写 goroutine +
bufio.Writer：显式设 buffer 大小（如16 * 1024），避免默认4KB太小 - 攒批写入：按数量（如 ≥100 条）或时间（如
50msticker）触发w.Flush()，再跟f.Sync() - 避免多 goroutine 写同一文件：即使带
os.O_APPEND，在 ext4/xfs 上仍可能因内核缓存导致行粘连或截断
真正丢数据的环节往往藏在 defer f.Close() 没写、f.Sync() 被跳过、或消费者 goroutine 没 recover 这几处——它们不报错，但一出事就是静默丢数据。
