zapcore.newasynccore是唯一靠谱的异步落盘入口，它内置无锁环形缓冲、单writer goroutine、批量flush和内存复用；启用需手动组装core，buffersize设1024–8192，writer必须为zapcore.writesyncer，关键错误日志须绕过异步通道直写并显式file.sync()。
zapcore.NewAsyncCore 是唯一靠谱的异步落盘入口
别用 go logger.Info() 或 log.SetOutput(bufio.NewWriter(...)) 充数——前者只是开 goroutine，没缓冲、无背压、不批量；后者只缓冲系统调用，格式化、JSON 序列化、runtime.Caller 全在主 goroutine 里跑，P99 延迟照样飙升。真正解耦“记录”和“落盘”，必须走 zapcore.NewAsyncCore。
它不是简单包一层 goroutine，而是内置无锁环形缓冲 + 单 writer goroutine + 批量 flush + 内存复用。启用方式固定：
logger := zap.New(zap.WrapCore(func(core zapcore.Core) zapcore.Core {
return zapcore.NewAsyncCore(encoder, writer, level, 4096)
}))
-
bufferSize设 1024～8192：128 太小易丢日志，65536 会导致 P99 延迟超 200ms -
writer必须是zapcore.WriteSyncer，不能直接传*os.File；得套zapcore.AddSync(zapcore.Lock(lumberjackLogger)) - 峰值 QPS 超 5w 时，纯内存缓冲扛不住，得加本地磁盘队列兜底（如
file-rotatelogs+io.MultiWriter）
关键错误日志必须绕过异步通道直写
异步本质是“尽力而为”。服务启动失败、DB 连接中断、核心 API 超时这类日志丢了就难定位，绝不能进 zapcore.NewAsyncCore 的环形缓冲。
正确做法是单独配一个带 os.O_SYNC 的 *os.File，专供 ERROR/PANIC 级别：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 打开文件时加
os.O_SYNC标志，确保 write 后立即落盘 - 每次写完必须显式调用
file.Sync()，别依赖defer logger.Sync()——进程崩溃时它根本不会执行 - 用独立 channel 或直接同步写，避免和异步路径共享任何 buffer 或锁
轮转日志别踩 lumberjack 的同步压缩坑
lumberjack 在 rotate 瞬间会同步执行 gzip 压缩，所有写入卡住，实测延迟飙到 200ms+，还会导致旧日志错写进新文件末尾（时间戳乱序）。
安全配置只有两条：
- 必须设
LocalTime: true和Compress: false—— 压缩操作绝对不能出现在写路径中 - 更稳方案：用
io.MultiWriter把日志同时写到当前文件 + 另起 goroutine 异步做 rotate，rotate 动作完全与写解耦 - Windows 下
file-rotatelogs文件锁行为和 Linux 不同，测试务必用目标 OS
自己手写 channel + batch 模型时最容易漏三件事
不用 zap 时，自己实现异步刷盘常以为 “make(chan *LogEntry, 1024) + go func() { for range ch { ... } }” 就够了，其实漏掉关键防护：
- 没加
recover：消费者 goroutine panic 后整个 channel 积压，进程退出时全丢 - 没设超时：从
取日志时没配 <code>select { case ，channel 长期阻塞会导致消费者僵死 - 退出前没等 flush：用
sync.WaitGroup等当前 batch 写完，但必须设 timeout（比如 2 秒），否则进程卡死
缓冲大小不是拍脑袋定的——先压测出峰值日志量（如 800 条/秒），再乘 3–5 倍设基准（如 4096），并加水位判断：len(ch) > cap(ch)*0.8 时降级或丢非关键字段。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
