Go语言无多线程概念，需用goroutine+WaitGroup+Scanner安全并发处理按行文本任务；多goroutine直读同一os.File会因共享文件偏移量导致跳行、重复或panic；正确做法是单goroutine读取+channel分发至worker池，或谨慎按行对齐分片。
Go 语言本身没有“多线程”概念，但用 goroutine + sync.WaitGroup + bufio.Scanner 可以安全高效地并发处理文本文件的**按行读取与分析任务**——前提是：每行独立、无状态依赖、不写回同一文件。
为什么不能直接用多个 goroutine 读同一个 *os.File
多个 goroutine 并发调用 file.Read() 或 scanner.Scan() 会竞争文件偏移量（file.Seek 是共享状态），导致跳行、重复读、甚至 panic。这不是并发安全的设计。
- 错误现象：
scanner.Scan()忽略部分行，或报unexpected EOF - 根本原因：
bufio.Scanner内部缓存和底层Read调用不满足并发读要求 - 正确做法：让一个 goroutine 独占读取，把每行发给 worker 池；或预分片（适用于大日志按行切分场景）
推荐方案：单读 + 多 worker 模式
这是最稳妥、内存可控、逻辑清晰的模式，适合日志解析、CSV 行过滤、关键词提取等典型文本处理场景。
- 主 goroutine 负责打开文件、逐行扫描，通过
chan string向 worker 池投递每行内容 - worker 数量建议设为
runtime.NumCPU()或略高（如 ×1.5），避免过度调度 - 使用带缓冲的 channel（如
make(chan string, 1000)），防止读取端阻塞 - 务必在发送前检查
scanner.Err()，否则可能漏掉最后几行或静默失败
func processLines(filename string, workers int) {
file, _ := os.Open(filename)
defer file.Close()
scanner := bufio.NewScanner(file)
lines := make(chan string, 1000)
<pre class='brush:php;toolbar:false;'>// 启动 worker
var wg sync.WaitGroup
for i := 0; i < workers; i++ {
wg.Add(1)
go func() {
defer wg.Done()
for line := range lines {
// 实际处理逻辑，例如：strings.Contains(line, "ERROR")
_ = processLine(line)
}
}()
}
// 单 goroutine 读取并分发
go func() {
for scanner.Scan() {
lines <- scanner.Text()
}
if err := scanner.Err(); err != nil {
log.Printf("scan error: %v", err)
}
close(lines)
}()
wg.Wait()}
立即学习“go语言免费学习笔记（深入）”；
大文件分片读行（需谨慎）
若必须物理分片（如 10GB 日志拆成 10 个 1GB 文件再并发读），关键不是“按字节切”，而是“按行对齐”——否则某行被截断在两个分片之间。
- 先用
os.Stat获取文件大小，再用os.Open+file.Seek定位到近似位置 - 从
seek点向后读直到遇到第一个\n，才开始正式解析（跳过不完整行） - 最后一片的结束位置必须是
fileSize - 1，且读完后要手动确认是否还有未处理的尾行 - 该方案复杂度高、易出错，仅当单读瓶颈明显（如 CPU 解析远快于磁盘读）且可接受预处理开销时考虑
bufio.Scanner 的缓冲区陷阱
默认 scanner.Buffer 最大只支持 64KB 行，超长行会直接返回 false 且 scanner.Err() 是 bufio.ErrTooLong，但这个错误容易被忽略。
- 现象：某些超长日志行（如堆栈+base64 payload）完全消失，无任何提示
- 解决：初始化后显式扩大缓冲区：
scanner.Buffer(make([]byte, 4096), 1（最大 1MB） - 注意：过大缓冲会增加内存占用，且无法规避单行超过 OS 页大小的极端情况
真正难的不是启动多少 goroutine，而是确保每行只被处理一次、不丢不重、不出错。单读分发看似“不够并发”，但在绝大多数文本处理场景中，它反而是吞吐最高、最稳的路径。
