17370845950

Go多协程写日志必须序列化输出，推荐channel+单goroutine方案：日志项发至带缓冲channel，由唯一后台goroutine顺序写入，确保完整性与逻辑顺序；次选sync.Mutex+bufio.Writer（需小粒度锁+Flush）；生产环境优先用Zap/Zerolog等成熟库。

Go 中多协程写日志时，不能直接共用一个 *os.File 或 io.Writer 并发写入，否则会出现内容错乱、覆盖、截断等问题。真正安全且能保持逻辑顺序（非绝对时间顺序）的关键，在于日志事件的序列化输出，而非依赖写入时机。下面从核心问题出发，给出实用、轻量、可落地的方案。

用 channel + 单 goroutine 序列化写入

这是最常用也最稳妥的方式：所有日志调用都把日志条目（如结构体或字符串）发到一个有缓冲的 channel，由**唯一一个后台 goroutine 顺序接收并写入文件**。这样天然避免竞争，也保证了日志行的完整性与相对顺序（即谁先发、谁先写）。

• 定义日志项结构，包含时间、级别、消息、协程标识等
• 启动一个长期运行的 writer goroutine：for entry := range logChan { writeToFile(entry) }
• 对外提供同步/异步日志函数，内部只做 logChan （注意加超时或非阻塞防止卡死）
• 缓冲区大小按峰值日志量设（如 1024），配合 select + default 实现丢弃或降级策略

用 sync.Mutex + bufio.Writer 提升吞吐（适合低频高一致性场景）

如果日志量不大（比如每秒几百条以内），且你希望减少 goroutine 调度开销，可用互斥锁保护带缓冲的 bufio.Writer。关键点是：锁粒度要小，且必须在每次写完后调用 Flush()，否则缓冲区内容可能滞留或跨日志行混粘。

• 全局声明 var (mu sync.Mutex; writer *bufio.Writer)
• 日志函数中：mu.Lock(); writer.WriteString(...); writer.WriteRune('\n'); writer.Flush(); mu.Unlock()
• 务必避免在锁内做耗时操作（如格式化复杂结构体），建议提前格式化好字符串再加锁写入
• 注意：Flush() 可能返回 error，需检查并处理（如重试或记录错误）

利用成熟库（zap / zerolog）简化开发

生产环境不建议手写日志系统。Zap 和 Zerolog 都原生支持多协程安全写入，并默认采用类似 channel 序列化的模型：

• Zap 的 Logger 是并发安全的，底层用 ring buffer + 单 writer goroutine
• Zerolog 默认也是 lock-free + channel 模式，可通过 zerolog.New(os.Stderr).With().Timestamp().Logger() 快速启用
• 两者都支持自定义 WriteSyncer（如轮转文件、网络发送），你只需专注日志内容，不用操心同步
• 开启 DisableCaller() 和 DisableStacktrace() 可进一步减少竞争点

避免踩坑：顺序 ≠ 实时，安全 ≠ 不丢日志

多协程日志的本质矛盾是：顺序性、性能、可靠性三者不可兼得。需根据场景权衡：

• “顺序”指逻辑顺序（如请求 A 的 start/finish 日志不被 B 插入中间），不是纳秒级精确时序 —— 这点必须接受
• channel 方案在进程崩溃时可能丢失 channel 中未消费的日志，如需强持久，应结合 sync.RWMutex + 内存 buffer + 定期刷盘，或使用 WAL 类设计
• 不要用 log.SetOutput() 直接设为文件句柄并发写 —— log 包本身不保证写入原子性
• 若需按天/大小轮转，务必确保轮转操作（close+open）也受同一锁/channel 保护，否则可能写入已关闭文件导致 panic