Go日志性能瓶颈在于同步I/O，优化核心是异步+批量：用bufio.Writer缓冲（64KB～256KB）、goroutine+channel异步消费、选zap等成熟库，并避免日志中高开销操作。
Go 日志性能瓶颈往往不在日志格式化，而在频繁的同步 I/O —— 每次 log.Print 或 zap.Info 都可能触发一次系统调用写磁盘。真正有效的优化是把“写日志”从关键路径中摘出来：用异步 + 批量，让业务逻辑不等 I/O，让磁盘写更少、更大、更稳。
用带缓冲的 Writer 替代直接写文件
标准库 log.SetOutput 接收任意 io.Writer，别直接传 *os.File。套一层 bufio.Writer 就能攒一批再刷盘，减少系统调用次数。
示例：
f, _ := os.OpenFile("app.log", os.O_WRONLY|os.O_CREATE|os.O_APPEND, 0644)
bufWriter := bufio.NewWriterSize(f, 64*1024) // 64KB 缓冲区
log.SetOutput(bufWriter)
// 别忘了在程序退出前 flush
defer bufWriter.Flush() // 或在信号处理中调用
注意：缓冲区大小要权衡 —— 太小（如 4KB）仍频繁刷；太大（如 1MB）可能丢日志（进程崩溃时未 flush）。64KB～256KB 是较稳妥的起点。
立即学习“go语言免费学习笔记（深入）”；
用 goroutine 脱离主流程做写入
缓冲 Writer 仍会阻塞（比如缓冲满或手动 flush 时），彻底解耦需异步：日志先发到 channel，由单独 goroutine 消费并批量写入。
关键点：
- channel 用带缓冲的（如
make(chan string, 1000)），避免日志激增时业务 goroutine 被卡住 - 消费者 goroutine 按时间（如每 10ms）或数量（如每 100 条）触发一次批量写，而非逐条处理
- 务必加超时或强制 flush 机制，防止日志滞留过久（尤其错误日志）
简单示意：
logs := make(chan string, 1000)
go func() {
batch := make([]string, 0, 128)
ticker := time.NewTicker(10 * time.Millisecond)
defer ticker.Stop()
for {
select {
case msg := <-logs:
batch = append(batch, msg)
if len(batch) >= 100 {
flushBatch(batch)
batch = batch[:0]
}
case <-ticker.C:
if len(batch) > 0 {
flushBatch(batch)
batch = batch[:0]
}
}
}
}()
选对日志库，省力又高效
自己实现异步+批量容易遗漏边界（如 panic 捕获、OOM 保护、优雅关闭）。成熟库已做好这些：
-
zap：默认就是异步（
zap.NewProduction()底层用lumberjack+ 无锁 ring buffer），支持Syncer自定义刷新策略 -
zerolog：零分配设计，配合
zerolog.ConsoleWriter的FlushInterval可控批量输出 -
logrus：需搭配
logrus.Async()插件或自建 hook，但默认非异步，需显式启用
推荐起步用 zap：启用它只需两行，性能和可靠性已远超手写：
logger, _ := zap.NewProduction() defer logger.Sync() // 关键：确保退出前刷完 // 后续所有 logger.Info() 都自动异步
避免日志本身拖慢性能
异步只能缓解 I/O，不能掩盖低效日志内容。以下习惯会让日志变慢，即使开了异步：
- 在日志里调用
time.Now().String()、fmt.Sprintf等高开销操作 —— 改用结构化字段（logger.Info("req", zap.String("path", r.URL.Path))） - 无条件打印 debug 日志（如循环内
log.Debug("i=", i)）—— 用日志等级开关 + 结构化字段延迟计算 - 记录大对象（如整个 HTTP body、原始数据库结果集）—— 记录摘要（长度、哈希、关键字段）即可
基本上就这些。异步写入不是银弹，但配合批量刷新和合理日志习惯，能让日志吞吐提升数倍，同时不增加业务延迟。不复杂，但容易忽略缓冲区大小和 flush 时机。
