优先用 chan string 而非 chan []byte：因行数据天然以 \n 为界，string 更贴近语义且不可变，避免多 goroutine 意外篡改；[]byte 虽省拷贝但需手动管理内存生命周期，易引发 panic 或脏读，仅超大日志且已池化时才选用。
为什么用 chan string 而不是 chan []byte 做行数据流水线
行数据天然以 \n 为界，string 更贴近语义且不可变，避免多个 goroutine 意外篡改同一块内存；[]byte 虽省拷贝，但需手动管理底层数组生命周期，容易在 channel 关闭后触发 panic: send on closed channel 或读到脏数据。除非处理超大日志（GB 级）且已做池化，否则优先选 string。
strings.TrimSpace 和 strings.TrimSpace 在过滤阶段的区别
两者行为完全一致，strings.TrimSpace 是标准库导出函数名，strings.TrimSpace 并不存在——这是常见拼写误导致编译失败的点。实际使用时只认 strings.TrimSpace。行过滤常见组合是：
-
strings.TrimSpace(line) == ""→ 跳过空行 -
strings.HasPrefix(line, "#")→ 跳过注释行 -
len(line) > 1024→ 截断超长行（防 OOM）
如何安全关闭双向通道并防止 goroutine 泄漏
双向通道（chan string）本身不区分读写方向，所谓“双向”是靠多个 goroutine 分别执行 send 和 recv 实现的。关键不是通道类型，而是关闭时机：只能由**唯一生产者**在所有数据发完后调用 close(ch)，消费者用 for line := range ch 自动退出。常见错误包括：
- 多个 goroutine 同时
close(ch)→ panic: close of closed channel - 消费者未用
range，而是循环且无超时/退出条件 → goroutine 永久阻塞 - 生产者提前关闭，但中间过滤 stage 还在往下游 channel 发数据 → “send on closed channel”
推荐结构：每个 stage 都接收上游 chan string，返回新的 chan string，由最上游启动 goroutine 写入，最下游消费，中间全部用 range + defer close(out)。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
性能瓶颈往往卡在 I/O，不是 channel
用 bufio.Scanner 逐行读文件时，默认缓冲区 64KB，若单行超长会触发 scanner.ErrTooLong；而 channel 本身无锁（底层是环形队列），千级并发下吞吐远高于磁盘或网络 I/O。实测中更值得调优的是：
- 把
os.Open替成os.OpenFile(path, os.O_RDONLY, 0)，显式禁用写权限，避免某些文件系统额外检查 - 给
bufio.Scanner设置更大缓冲：scanner.Buffer(make([]byte, 64*1024), 1 - 过滤逻辑避免在 goroutine 中调用
regexp.Compile，应提前编译好复用
真正需要加 buffer 的 channel 是那些计算密集型 stage（如 base64 编码），可设 make(chan string, 128) 防止上游 push 太快压垮下游，但纯文本过滤一般 0 缓冲即可。
