真异步日志必须带缓冲、批量落盘与背压控制，否则高并发下会丢日志、oom或卡主流程；go log.printf()仅挪写入到新goroutine，未解决格式化同步、并发写文件竞争、无缓冲等根本问题。
直接结论：异步写盘不是加个 go log.Printf() 就完事，真正能提效的必须带缓冲、批量、背压控制，否则高并发下要么丢日志、要么 OOM、要么卡死主流程。
为什么 go log.Printf() 是伪异步
它只是把同步写操作扔进新 goroutine，但没解决三个根本问题：日志内容没提前拼好，log.Printf() 内部仍要格式化 + 锁 + Write()；多个 goroutine 并发写同一文件句柄，会触发内核级竞争（尤其在 ext4/xfs 上）；无缓冲 channel 或无界 goroutine 启动，流量突增时直接拖垮调度器。
- 现象：pprof 显示大量时间耗在
syscall.Syscall和runtime.futex - 后果：HTTP handler 响应延迟毛刺明显，日志时间戳错乱，进程退出时最后 200ms 日志全丢
- 关键点：
log包本身不支持无锁写入，SetOutput指向bufio.Writer也只缓到内核 buffer，Flush()仍阻塞
zapcore.NewAsyncCore 为什么比手写 channel 更稳
它不是简单包一层 goroutine，而是内置无锁环形缓冲、双触发 flush（满载或超时）、内存复用和 panic 恢复。手写 chan *LogEntry 很容易漏掉 recover、default 降级、rotate 协程卡死等边界。
- 缓冲区大小建议设为
1024～8192：小于 1024 容易满载丢日志，大于 8192 GC 压力陡增且延迟升高 - 峰值超 5w QPS 时，纯内存缓冲扛不住，需搭配磁盘队列（如
file-rotatelogs+io.MultiWriter） - 必须配
default分支做降级：channel 满时写os.Stderr或打监控指标，不能直接丢弃
自研异步刷盘必须含这四件事
不用第三方库也能跑通，但缺一不可：带缓冲 channel、单写 goroutine、bufio.Writer 批量攒写、显式 file.Sync() 控制落盘时机。
-
logChan := make(chan *LogEntry, 1024)：容量按压测峰值 ×3～5 设（如 800 条/秒 → 4096） -
w := bufio.NewWriterSize(file, 16*1024)：避免默认 4KB 太小，导致 flush 频次过高 - batch 切片预分配容量：
make([]*LogEntry, 0, 128)，防止扩容抖动 -
w.Flush()≠ 落盘，file.Sync()必须显式调用，尤其 ERROR/PANIC 级别
脱敏必须在主线程完成，不能放后台 goroutine
后台 goroutine 中访问 *http.Request 或动态租户上下文，大概率 panic；脱敏逻辑（如正则编译、JSON 解析）还会拖慢批量 flush 节奏，反向卡住业务。
- 正确路径：主线程生成终态
LogEntry（字段白名单 + 预编译正则 + 浅拷贝），再发往logChan - 错误做法：在消费 goroutine 里调用
redactPassword(req)，req已被回收，panic 报invalid memory address - 结构化脱敏更稳：让业务 struct 实现
MarshalLogObject，由自身控制哪些字段暴露、哪些掩码
真正难的不是“怎么异步”，而是“什么时候不该异步”和“异步失败了怎么知道”。通道满载、writer goroutine panic、rotate 卡死、关键日志没落盘——这些点都得有独立监控和兜底，而不是靠 defer logger.Sync() 一招鲜。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
