go 中无法真正并行读取单个文件流，因为文件读取本质是串行的字节流操作；若需并发处理文本内容，应先顺序读取再分发单词到 goroutine，或通过文件分块（seek/read）实现真正的并行解析。
在 Go 中，并发读取一个文本文件（如按单词或行处理）常被误解为“用多个 goroutine 同时调用 Read()”，但这是不成立且不可行的。原因在于：os.File 是一个共享的、有状态的 I/O 流，底层基于系统调用（如 read(2)），其读取位置（offset）是全局的。多个 goroutine 并发调用 Read() 或 Scanner.Scan() 会相互干扰，导致数据错乱、重复或遗漏——这并非 Go 的限制，而是操作系统层面的 I/O 模型决定的。
✅ 正确的并发策略分两类：
1. 顺序读取 + 并发处理（推荐，简单安全）
先用单个 goroutine（通常是主线程）顺序读取全部内容（或逐行/逐块读取），再将解析出的单元（如单词、行）发送至 channel，由一组 worker goroutine 并发处理：
package main
import (
"bufio"
"fmt"
"os"
"strings"
"sync"
)
func main() {
file, _ := os.Open("input.txt")
defer file.Close()
scanner := bufio.NewScanner(file)
wordsCh := make(chan string, 1000) // 缓冲 channel 避免阻塞
// Producer: 提取所有单词（顺序）
go func() {
defer close(wordsCh)
for scanner.Scan() {
line := scanner.Text()
for _, word := range strings.Fields(line) {
wordsCh <- word
}
}
}()
// Consumers: 并发处理单词（顺序无关）
var wg sync.WaitGroup
results := make([]string, 0, 1000)
mu := &sync.Mutex{}
for i := 0; i < 4; i++ { // 启动 4 个 worker
wg.Add(1)
go func() {
defer wg.Done()
for word := range wordsCh {
// 模拟耗时处理，如正则匹配、HTTP 请求等
processed := strings.ToUpper(word)
mu.Lock()
results = append(results, processed)
mu.Unlock()
}
}()
}
wg.Wait()
fmt.Println("Processed words (order not guaranteed):", results)
}✅ 优势：线程安全、逻辑清晰、无竞态、适用于绝大多数场景（如日志分析、词频统计）。 ⚠️ 注意：strings.Fields() 已足够高效；避免在 goroutine 中重复打开文件或共享未加锁的切片。
2. 文件分块并行读取（仅适用于超大文件且 I/O 确为瓶颈）
若文件达 GB 级别，且你已确认顺序读取成为性能瓶颈（需实测验证），可手动分片：使用 file.Seek() 定位起始偏移，file.Read() 读取固定大小块，再在每个 goroutine 内完成边界对齐（如确保不截断单词）、解析与聚合。但这需要精细控制（如跳过行首不完整 UTF-8 字符、处理跨块换行符），复杂度高，不建议新手尝试。
❌ 错误示例（禁止！）：
// 危险！多个 goroutine 共享 scanner → 数据竞争
go func() { scanner.Scan(); process(scanner.Text()) }()
go func() { scanner.Scan(); process(scanner.Text()) }() // ❌ 不可预测行为总结
- 不要为并发而并发：bufio.Scanner 本身已高度优化，顺序读取百万行文本通常只需毫秒级。
- 优先选择「顺序读 + 并发处理」模式：它解耦了 I/O 与计算，既安全又符合 Go 的并发哲学。
- 真正的并行文件读取只在极少数场景下必要，且必须绕过高层封装（Scanner），直接操作 os.File 和 Seek，并自行解决分片边界问题。
- 始终用 go run -race 检测数据竞争，用 pprof 分析真实瓶颈——而不是凭直觉添加 goroutine。
