首选zapcore.newasynccore，因其内置无锁环形缓冲、双触发flush等机制；手写channel必须同时满足缓冲区满、定时器超时、关闭强制flush三条件，否则必丢日志或延迟飙升。
直接上结论：用 zapcore.NewAsyncCore，别手写 channel + goroutine；如果非要自研，必须同时满足「缓冲区满触发」+「定时器超时触发」+「关闭时强制 flush」三条件，否则线上必然丢日志或延迟飙升。
为什么 zapcore.NewAsyncCore 是首选
它不是简单起个 goroutine 包一层，而是内置无锁环形缓冲、内存复用、双触发 flush（满载 + 超时）、失败重试和监控回调。手写 channel 容易漏掉背压控制——logChan := make(chan *LogEntry, 1024) 满了之后不处理，业务调用方要么阻塞（没加 select { case ...: default: }），要么 panic。
- 缓冲大小默认
1024，适合大多数场景；峰值 QPS 超 5w 时建议配lumberjack.Logger做本地磁盘队列兜底 - 超时默认
1s，低流量时段不会卡住日志；突发流量下也不会因单次 flush 太大而拖慢 writer goroutine - 关键错误日志可绕过异步通道：
logger.WithOptions(zap.WrapCore(...)).With(zap.String("urgent", "true"))配合自定义 core 实现直写
自研 channel 批量刷盘必须带双触发机制
只靠 len(batch) >= 100 flush，低流量时日志可能卡在内存里几秒不出；只靠 time.Ticker(50 * time.Millisecond)，高流量下 batch 可能暴涨到几千条，一次 flush 卡住 writer，拖慢整个系统。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确做法是两个条件都监听：
select { case entry := -
batch切片要用batch[:0]清空，避免底层数组残留导致 GC 压力或数据错乱 - 每次
w.Flush()后必须跟file.Sync()，否则只是刷到内核 buffer，断电或 crash 会丢日志
bufio.Writer 缓冲大小不能依赖默认值
bufio.NewWriter(file) 默认只用 4KB 缓冲，对日志这种小而密的写入非常低效；实测批量写 100 条日志时，16*1024 比默认快 2～3 倍。
- 显式指定大小：
bufio.NewWriterSize(file, 16*1024) - 不要在每次 flush 后重建
bufio.Writer，复用同一个实例，避免反复 malloc - 注意
file必须是*os.File，不能是io.Writer抽象接口，否则file.Sync()会编译失败
非阻塞写入必须加 default 分支
业务代码调 logger.Info() 时，如果 channel 满了还硬塞，会直接卡住主 goroutine——HTTP handler 延迟从 2ms 突然跳到 50ms+ 就是这么来的。
- 必须用
select { case logChan - 丢弃不是最优解，但比阻塞强；更稳妥的是 fallback 到同步写 stderr 或本地临时文件
- channel 容量设太小（如
128）会导致频繁触发 default；太大（如8192）会让低流量日志延迟不可控
最容易被忽略的是：writer goroutine 退出前必须 drain channel 并 flush 剩余 batch，否则 os.Exit() 或 panic 时日志直接消失。这个步骤没法靠 defer 自动完成，得手动监听信号或调用 Close() 显式触发。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
