zapcore.NewAsyncCore比手写chan更稳，因其内置无锁环形缓冲、批量刷盘和内存复用，避免背压失控、OOM及panic丢日志；缓冲区建议1024～8192，超5w QPS需搭配磁盘队列。
Go 日志文件异步写入不是“加个 goroutine 就完事”，核心是解耦「记录」和「落盘」，同时防止背压失控、panic 丢日志、rotate 卡死这三类生产事故。
为什么 zapcore.NewAsyncCore 比手写 chan *LogEntry 更稳
自己用 chan *LogEntry 容易漏掉关键边界：没 default 分支导致主 goroutine 卡死；没 recover 导致 writer goroutine 因文件句柄失效后静默退出；缓冲区满时直接丢日志却无告警。而 zapcore.NewAsyncCore 内置无锁环形缓冲 + 批量刷盘 + 内存复用，不是简单包一层 goroutine。
- 缓冲区大小建议设为
1024～8192：太小易满丢日志，太大增加延迟 - 峰值超
5w QPS时，纯内存缓冲扛不住，需搭配本地磁盘队列（如file-rotatelogs+io.MultiWriter） - 别用
select { case ch 就结束——必须加default分支做降级（如写os.Stderr或打监控指标）
os.O_SYNC 和 os.O_APPEND 怎么配才不拖慢性能
os.O_SYNC 会让每次 write 都等磁盘物理写入完成，P99 延迟直接跳变，只该用于 error 和 panic 级别直写路径；普通日志一律用 os.O_APPEND + bufio.Writer 缓冲，且必须定期 Flush()（每秒或每 1MB），不能只靠 defer writer.Flush()。
- 打开文件用：
os.OpenFile("app.log", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644) - 包装缓冲器：
w := bufio.NewWriterSize(file, 32*1024)，太小（128KB）可能延迟落盘 - 写入后别忘了检查：
if w.Available() == 0 { w.Flush() }，或定时触发 flush
lumberjack.Rotate 为什么会卡住所有日志写入
lumberjack 在 rotate 瞬间会同步压缩归档，所有写入被阻塞，实测延迟飙到 200ms+，还会导致日志时间戳乱序（旧日志写进新文件末尾）。它不适合高并发实时日志场景。
- 必须设
LocalTime: true和Compress: false，压缩操作绝不能在写路径里做 - 更稳做法：用
io.MultiWriter把日志同时写到当前文件 + 另一个 rotate goroutine，rotate 动作完全异步 - Windows 下
file-rotatelogs文件锁行为和 Linux 不同，测试务必用目标 OS
真正难的不是“怎么异步”，而是“什么时候不该异步”和“异步失败了怎么知道”。异步通道满载、writer goroutine panic、rotate 卡死、关键日志没落盘——这些点都得有独立监控和兜底，而不是靠 defer logger.Sync() 一招鲜。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
