使用 Go 语言实现多协程并发日志写入的正确模式

本文详解如何在 Go 中通过多个 goroutine 安全、均匀地消费同一 channel，避免因误用全局 log 包导致所有日志被写入最后一个 worker 文件的问题，并提供线程安全、可维护的日志分发方案。

在 Go 项目里，让多个 goroutine 并发处理日志是提升性能的常见思路。但不少开发者会遇到一个“诡异”的现象：明明启动了四个 worker，最后却发现所有日志都堆在了最后一个文件里。问题出在哪儿？今天就来拆解这个典型的并发陷阱，并给出一个既安全又高效的解决方案。

✅ 正确做法：为每个 Worker 创建独立 Logger 实例

问题的根源，其实不在 channel 本身。Go 语言中，多个 goroutine 从同一个 channel 接收数据（也就是“扇出”模式）是完全可行的。真正的坑在于，很多代码里都习惯性地使用了 log.SetOutput()。

这里有个关键细节必须警惕：log.SetOutput() 操作的是 Go 标准库里的全局默认 logger。这意味着，当四个 worker 几乎同时启动时，最后一个调用 log.SetOutput() 的 goroutine 会覆盖掉前面的设置。结果就是，无论日志来自哪个 worker，最终都会流向最后一个被设置的文件句柄。

那么，正确的姿势是什么？答案是：彻底告别全局配置，为每个 worker 配备专属的 logger 实例。使用 log.New() 来构造，让每个 logger 管理自己的输出目标，彼此井水不犯河水。

func (lw *LogWorker) Work(evChannel chan Event) {
    fmt.Printf("Worker started: %s\n", lw.FileName)
    // ✅ 每个 goroutine 持有独立 logger，互不干扰
    lg := log.New(&lumberjack.Logger{
        Filename:   lw.FileName,
        MaxSize:    lw.MaxSize,
        MaxBackups: lw.MaxBackups,
        MaxAge:     lw.MaxAge,
    }, "", 0) // 前缀为空，标志位为 0（禁用时间戳等，默认由 lumberjack 处理）
    // ✅ 使用 range 遍历 channel，优雅退出
    for event := range evChannel {
        lg.Println(Csv(event))
    }
}

为什么 range 更优？
使用 for event := range evChannel 不仅代码更简洁，更重要的是语义清晰：当 channel 被关闭后，循环会自动、优雅地退出。相比之下，传统的 for { event := <-evChannel } 在 channel 关闭后会持续接收到零值，这不仅会产生无效日志，如果下游的 Csv() 函数依赖非零字段，甚至可能引发 panic。这可是 Go channel 使用中的一个关键细节。

⚠️ 其他关键注意事项

解决了 logger 独立性的问题，一个健壮的日志系统还需要考虑下面几个方面：

• Channel 容量与背压：示例中 make(chan Event) 创建的是无缓冲 channel。在高并发场景下，虽然用 select 配合 time.After 能防止程序阻塞，但代价是可能丢失日志。更稳妥的做法是使用带缓冲的 channel（例如 make(chan Event, 1000)），并辅以监控，观察缓冲区是否有堆积情况。

• Worker 生命周期管理：生产环境下的服务必须支持优雅退出。可以在 main() 函数中通过 signal.Notify() 捕获 SIGTERM 等信号，然后安全地关闭日志 channel。这样，所有正在使用 for range 循环的 worker 都会自然结束工作。

• 结构体定义完整性：确保你的 Event 结构体和 Csv() 序列化函数已正确定义。需要特别注意的是，Csv() 函数应返回 string 类型，否则传递给 lg.Println() 时可能会产生非预期的输出格式。

✅ 完整修复要点总结

遵循以上方案调整后，你的四个 LogWorker 才能真正实现均匀的负载分担，各自将日志写入独立的文件（例如 event_0, event_1…）。这样一来，“所有日志只写入最后一个文件”的问题将得到彻底解决，整个日志系统的设计也更符合 Go 并发编程的最佳实践，兼具高性能与高可维护性。