用 bufio.Scanner + chan string 构建单向管道最安全高效，内存恒定几 MB；需显式复制 scanner.Text() 结果避免缓冲区覆盖错误，缓冲通道大小宜设为 10–100 并配 4–8 个消费者实现背压。
直接上结论：用 bufio.Scanner + chan string 构建单向管道，比一次性读取或裸 goroutine 循环安全得多，且内存恒定在几 MB 级别——关键不是“并发越多越快”，而是让读、算、写三阶段不互相卡住。
为什么不能直接 for range scanner.Text() 启动 goroutine
因为 scanner.Text() 返回的是内部缓冲区的引用，多个 goroutine 同时调用会读到错乱内容，甚至 panic。这不是竞态检测能捕获的“数据竞争”，而是底层字节切片被反复覆盖导致的静默错误。
- 必须显式复制字符串：
line := scanner.Text(); go processLine(line) - 不能把
scanner实例传进闭包里复用 - 如果处理逻辑含正则匹配或 JSON 解析，更要警惕字符串逃逸——建议用
strings.Clone()（Go 1.20+）或手动string([]byte(line))强制分配新底层数组
如何设计带背压的 channel 管道
无缓冲 chan string 容易让生产者（读取协程）卡死在发送上；缓冲太大（如 make(chan string, 100000)）又会导致内存暴涨，尤其当某行日志平均 200 字节时，10 万缓冲就是 20MB 占用。
- 推荐缓冲大小为
10–100，配合固定数量消费者（如 4–8 个写入协程）形成自然背压 - 用
sync.WaitGroup等待所有行处理完成后再close(ch)，避免消费者提前退出 - 不要用
for range ch在多个消费者中——它只适合单消费者；多消费者应改用for { select { case line, ok :=
写入层必须用 bufio.Writer 批量刷盘
每行都 fmt.Fprintln(outFile, line) 会产生大量小 write 系统调用，I/O 效率极低。实测显示，未缓冲写入吞吐可能只有缓冲写的 1/5。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 每个写入协程维护自己的
*bufio.Writer，BufferSize设为 4KB 或 32KB（默认值） - 批量写入后记得
wr.Flush()，并在协程退出前补一次（防止最后一块没刷出） - 目标文件要用
os.O_CREATE | os.O_WRONLY | os.O_APPEND打开，避免覆盖已有内容
scanner.Err() 检查常被忽略但极其关键
scanner.Scan() 返回 false 不代表读完了——可能是磁盘损坏、权限不足、编码异常等错误被静默吞掉。不检查 scanner.Err()，你会以为文件处理成功，实际漏掉最后几千行。
- 循环结束后必须加：
if err := scanner.Err(); err != nil { log.Printf("scan error in %s: %v", fname, err) } - 特别注意：
ioutil.ReadFile和os.ReadFile也会掩盖 I/O 错误细节，大文件场景坚决不用
真正难的不是写对第一个 goroutine，而是让整条管道在 5 个 400 万行文件同时流过时，不出错、不泄漏、不 OOM、不丢数据——这要求每个环节都做“边界防御”：缓冲大小有依据、channel 关闭有顺序、错误检查不跳过、资源释放不延迟。
