zapcore.newasynccore比手写chan更稳，因其内置无锁环形缓冲、批量刷盘和内存复用，避免背压失控、oom及panic丢日志；缓冲区建议1024～8192，超5w qps需搭配磁盘队列。
直接用 log.Printf 或同步写文件扛不住海量日志，主 goroutine 会被 syscall.Write 卡住，P99 延迟跳变、QPS 断崖下跌是典型信号。必须把日志“记录”和“落盘”彻底解耦。
为什么 zapcore.NewAsyncCore 比手写 chan *LogEntry 更稳
自己用 chan *LogEntry 看似简单，但容易漏掉背压、OOM、panic 后静默丢失等关键问题。zap 的 zapcore.NewAsyncCore 内置无锁环形缓冲 + 批量刷盘 + 内存复用，不是简单包一层 goroutine。
- 缓冲区大小建议设为
1024～8192：太小易满导致丢日志，太大增加延迟 - 峰值超 5w QPS 时，纯内存缓冲扛不住，需搭配本地磁盘队列（如
file-rotatelogs+io.MultiWriter） - 别用
select { case ch 就完事——没 <code>default分支会卡死主流程；没 recover 会因文件句柄失效导致整个 writer goroutine 挂掉
关键错误日志必须绕过异步通道直写
异步本质是“尽力而为”，但像数据库连接失败、服务启动崩溃这类日志，丢了就无法定位根因。不能依赖 defer logger.Sync()，进程崩溃时它根本不会执行。
- 单独开一个带
os.O_SYNC标志的*os.File，只用于error和panic级别 - 直写路径要检查文件有效性：
file != nil && file.Fd() != ^uintptr(0)，避免invalid argument错误 - 格式化尽量前置：时间戳用
time.Now().UnixNano()存整数，而非每次调Format()
轮转日志别踩 lumberjack 的阻塞坑
lumberjack 在 rotate 瞬间会同步压缩归档，所有写入被阻塞，实测延迟飙到 200ms+，还会导致日志时间戳乱序（旧日志写进新文件末尾）。
- 必须设
LocalTime: true和Compress: false，压缩操作绝不能在写路径里做 - 更稳做法：用
io.MultiWriter把日志同时写到当前文件 + rotate goroutine，rotate 动作完全异步 - Windows 下
file-rotatelogs文件锁行为和 Linux 不同，测试务必用目标 OS
真正难的不是“怎么异步”，而是“什么时候不该异步”和“异步失败了怎么知道”。生产环境里，异步通道满载、writer goroutine panic、rotate 卡死、关键日志没落盘——这些点都得有监控和兜底，而不是靠 defer Sync() 一招鲜。
