go中用fan-in模式合并日志通道的核心是select+goroutine：每个输入源启独立goroutine拉取数据，主goroutine仅通过select转发，避免因某通道无数据导致整体阻塞。
Go 里用 fan-in 模式合并多个日志通道，核心就两行
不是靠第三方库，也不是写调度器，而是用 select + goroutine 把多个 chan string（或 chan []byte）安全地汇入一个统一输出通道。关键在于：每个输入源必须起独立 goroutine 拉取，主 goroutine 只负责 select 转发，否则会阻塞。
- 别直接在主逻辑里循环读多个 channel——一旦某个 channel 暂时没数据，整个聚合就卡住
- 每个日志源（比如不同微服务实例、不同模块）应启动自己的 goroutine：
go func() { for log := range srcChan { outChan - 输出通道建议带缓冲：
make(chan string, 1024)，避免下游消费慢导致上游 goroutine 阻塞
为什么不用 sync.WaitGroup 等所有日志 goroutine 结束再关通道
分布式日志是持续流，不是批处理任务。等“全部结束”意味着系统停机，而实际场景中，节点可能随时上线/下线、网络抖动、日志源重启——WaitGroup 无法应对这种动态性。
- 关闭聚合通道的唯一合理时机，是整个日志收集器被明确 shutdown（比如收到
SIGTERM） - 单个日志源 goroutine 出错（如连接断开），应该记录错误后自行退出，不影响其他源；可用
recover包裹或检查 channel 关闭状态 - 若用
for range读源 channel，要意识到：源 channel 关闭后该 goroutine 自然退出，但聚合通道仍需保持开放，直到所有源都退出或显式关闭
fanIn 函数封装时，别漏掉 context 控制生命周期
裸写 select 容易忽略取消信号，导致 goroutine 泄漏。尤其在 k8s 环境下，pod 重建时旧进程未退出，日志 goroutine 就会堆积。
- 每个拉取 goroutine 都要监听
ctx.Done()，并在退出前清理资源（如关闭 TCP 连接、释放 buffer） - 聚合通道本身不接收 context，但创建它的函数应接受
context.Context参数，并在ctx.Done()触发时关闭输出通道 - 示例片段：
func fanIn(ctx context.Context, chans ...<code>chan string</code>) <code>chan string</code> { out := make(chan string, 1024) go func() { defer close(out) for _, ch := range chans { go func(c <code>chan string</code>) { for { select { case log, ok := <code><span><code><span>log</span></code></span></code> <code><span><code><span>= range c</span></code></span></code>: if !ok { return } select { case out <code><span><code><span><= log</span></code></span></code>: case <code><span><code><span><-= ctx.Done()</span></code></span></code>: return } case <code><span><code><span><-= ctx.Done()</span></code></span></code>: return } } }(ch) } }() return out }
日志格式不一致时，fanIn 后立刻做标准化，别拖到写入阶段
不同服务可能输出 JSON、纯文本、带时间戳或不带，如果等到写入文件或发给 Loki 时再解析，会放大错误影响范围（比如一个坏日志让整个批次失败）。
立即学习“go语言免费学习笔记（深入）”；
- 在每个源 goroutine 内完成基础清洗：去除 control chars、补全缺失字段（如 service_name）、统一时间戳格式
- 用
json.RawMessage或结构体指针传递日志，比string更利于后续过滤和采样；但注意内存逃逸，大日志建议复用bytes.Buffer - 避免在
select分支里做耗时操作（如正则匹配、HTTP 请求），否则会拖慢整个 fan-in 吞吐；可先转发原始日志，另起 worker pool 异步处理
真正难的从来不是把几个 channel 合起来，而是当某个服务突然每秒打 5000 条 debug 日志、另一个服务输出的 timestamp 是毫秒字符串而你的 parser 期望纳秒整数、或者某次部署后一半节点还在用旧版日志 schema——这些时刻，fanIn 的健壮性全看初始化时有没有设好 buffer 大小、超时控制和错误隔离粒度。
