不能直接用goroutine 调 log.Printf 写文件,因 *log.Logger 非并发安全,多 goroutine 并发写同一文件会引发竞态,导致日志错乱、截断或丢失。
log.Printf 写文件直接起 goroutine 调 log.Printf 看似异步,但若底层是 os.File 且未加锁,多个 goroutine 并发写同一文件会触发竞态(race),日志行可能错乱、截断甚至丢失。Go 标准库的 *log.Logger 本身不是并发安全的——除非你手动包装锁,否则不推荐裸奔。
核心思路:所有日志调用都先发到一个带缓冲的 chan string,由唯一后台 goroutine 顺序消费并写入磁盘。这样既解耦了业务逻辑与 I/O,又天然避免竞态。
1024 或根据 QPS 估算,太小易阻塞调用方,太大占内存os.O_APPEND | os.O_CREATE | os.O_WRONLY 打开,避免覆盖或 truncatepackage mainimport ( "log" "os" "time" )
func asyncLogger(logFile string) (chan<- string, func()) { ch := make(chan string, 1024) f, err := os.OpenFile(logFile, os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644) if err != nil { log.Fatal(err) }
go func() { defer f.Close() for line := range ch { _, _ = f.WriteString(time.Now().Format("2006-01-02 15:04:05") + " " + line + "\n") _ = f.Sync() // 确保落盘,可按需去掉提升吞吐 } }() return ch, func() { close(ch) }}
func main() { logger, shutdown := asyncLogger("app.log") defer shutdown()
logger <- "user login success" logger <- "db query took 12ms"}
使用
zap的Core+WriteSyncer更稳妥手写 channel 容易漏掉错误处理、flush 控制、滚动切割等。生产环境强烈建议用
go.uber.org/zap,它原生支持异步模式,且WriteSyncer可自定义——比如把日志先写进bufio.Writer缓冲,再定期 flush。
zap.NewProductionConfig().EncoderConfig.EncodeTime = zapcore.ISO8601TimeEncoder 控制时间格式zap.WrapCore(func(core zapcore.Core) zapcore.Core { return zapcore.NewTeeCore(core) }) —— 实际更常用的是 zap.AddCaller() + zap.IncreaseLevel() 配合 zapcore.Lock
zapcore.Lock 是对 io.WriteSyncer 加锁,不是对整个 Core,所以仍需确保 WriteSyncer 本身线程安全异步日志最隐蔽的问题不是写不进去,而是“以为写进去了,其实没落盘”。比如进程 crash 前未 flush,或 channel 满了导致调用方阻塞(尤其在 defer 或 panic recovery 中)。
signal.Notify 捕获 os.Interrupt 和 syscall.SIGTERM,提前 close channel 并 waitf.Sync() 虽快,但断电或 kill -9 会导致最后几条日志消失 → 权衡点在于是否接受“最多丢 N 秒日志”len(ch),超阈值打 warning 或丢弃低优先级日志