go并发需用结构化流水线+显式节流，禁用无限制goroutine；应以带缓冲channel和worker pool控制并发数，每个worker独占资源，文件操作须独立open/close，大文件优先分块读取。
goroutine 不是线程，但常被误称为“多线程”——Go 用轻量级协程实现并发，关键在于控制数量、隔离资源、避免共享句柄。
直接为每行或每个文件无节制起 goroutine，程序大概率卡死或崩溃。真正有效的并行处理，靠的是结构化流水线 + 显式节流。
为什么不能直接用 for range + go processLine()
常见错误写法：
for _, line := range lines {
go processLine(line) // 错！lines 是切片，line 是循环变量引用
}
问题不止于数据竞争：processLine 若含 I/O 或解析逻辑，10 万行就可能拉起 10 万个 goroutine，内存暴涨、调度开销压垮 runtime。
- 闭包捕获循环变量
line，所有 goroutine 实际读到的是最后一行值 - 没限制并发数，
runtime.GOMAXPROCS和系统文件句柄数很快被耗尽 - 没收集结果或错误，无法判断哪些行失败、是否全部完成
用带缓冲 channel + worker pool 控制并发数
核心是把“任务投递”和“执行”解耦：生产者往 chan *LineJob 里塞任务，固定 N 个 worker 从 channel 消费并执行。
- worker 数量通常设为
runtime.NumCPU()或略高（如 4–16），取决于任务是 CPU 密集还是 I/O 密集 - channel 缓冲大小建议设为 worker 数的 2–5 倍（如
make(chan *LineJob, 32)），防生产者阻塞 - 每个 worker 必须有自己的
bufio.Scanner实例，不能复用同一 scanner 实例
示例片段：
jobs := make(chan *LineJob, 32)
results := make(chan error, 1000)
<p>for i := 0; i </p><p>// 投递任务
for _, line := range lines {
jobs </p>
多个文件时，别在 main 里 open 所有文件再传指针
典型坑：defer file.Close() 写在 main 函数里，但 processFile 需要实时读取——文件句柄会在 main 返回时才关，期间可能被重复读或泄漏。
- 正确做法：每个
processFile自己os.Open()和defer f.Close() - 若需预加载元信息（如文件大小），可只读一次
os.Stat()，不打开文件本体 - 绝对不要把
*os.File传给多个 goroutine 共享写入；写同一目标文件必须用sync.Mutex或单 writer goroutine + channel
大文件分块读取比按行更稳
bufio.Scanner 默认缓冲 64KB，遇到超长行会 panic；而 io.ReadFull + 固定 buffer 能规避此问题。
- 对日志类纯文本，优先用
scanner.Scan()，但务必设置scanner.MaxScanTokenSize - 对二进制或不确定格式的大文件，用
bufio.NewReaderSize(f, 1（1MB 缓冲），配合 <code>reader.Read(p []byte)分块处理 - 每块处理完立即写入临时文件，而非攒全量再 flush，防止 OOM
真正难的不是“怎么并发”，而是判断哪一层该并发、哪一层该串行、哪里该加锁、哪里该关 channel。这些边界稍一模糊，程序就从快变成不可靠。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
