Go 不支持文件分片并行读取，因 os.File 共享 offset 且非线程安全；正确做法是每个 goroutine 独立 os.Open + Seek + io.ReadFull，并对齐数据结构边界，避免竞态与短读。
直接上结论：Go 本身不支持文件分片并行读取（os.File 是共享的、不可安全 seek 多次并发读），所谓“分片并行”必须手动计算字节偏移 + 多个独立 os.Open 句柄 + 各自 file.Seek() 定位，否则会数据错乱或 panic。
为什么不能直接用 goroutine 并发调用同一个 *os.File.Read()
同一个 *os.File 实例维护一个内部读写偏移（offset），所有 Read() 调用都从当前 offset 开始，并自动推进。多个 goroutine 并发调用它，等价于在竞态条件下修改同一变量——结果不可预测：可能重复读、跳过段、或 io.ErrUnexpectedEOF 频发。这不是 bug，是设计使然。
- 常见错误现象：
read /path/to/file: bad file descriptor或部分 goroutine 读到空 slice - 即使加 mutex 锁住
file.Read()，也退化为串行，失去并行意义 -
bufio.Reader同样不解决根本问题，它只是封装了Read()，仍依赖底层 file 的 offset
正确做法：每个 goroutine 持有独立文件句柄 + 显式 Seek()
核心是放弃“共享句柄”，改为每个分片启动前 os.Open() 一次，然后 file.Seek(offset, io.SeekStart) 定位，再读指定长度。这样各 goroutine 完全隔离，无共享状态。
- 必须用
io.ReadFull()（而非file.Read()）确保读满目标字节数，避免因系统调用返回短读导致解析错位 - 分片边界要对齐实际数据结构：比如每条记录固定 512 字节，则起始 offset 必须是 512 的倍数，否则
Seek()落在记录中间，后续解析全崩 - 最后一个分片长度不固定，需按
min(chunkSize, remainingBytes)动态计算缓冲区大小 - 示例关键片段：
f, _ := os.Open(fileName) defer f.Close() f.Seek(int64(offset), io.SeekStart) buf := make([]byte, chunkSize) _, err := io.ReadFull(f, buf) // 注意不是 f.Read(buf)
性能瓶颈和容易被忽略的点
开太多文件句柄会触发 too many open files 系统限制；seek + read 的随机 IO 在机械硬盘上比顺序读慢很多；而且 Go 的 os.Open() 是系统调用，不是零成本操作。
立即学习“go语言免费学习笔记（深入）”；
- 并发数别硬写
runtime.NumCPU()—— 这适合 CPU 密集型，而文件 IO 是 IO 密集型，建议从 4–8 起调，观察iostat -x 1的 %util 和 await - 每个 goroutine 的
os.Open()必须配defer f.Close()，漏掉就会快速耗尽 fd 限额 - 若文件内容需校验（如 CRC32），不要在 goroutine 内部边读边算——先完整读进内存再算，否则
io.ReadFull()的阻塞会拖慢整体吞吐 - SSD 上随机 seek 成本低，但若分片太小（如
真正难的不是并发逻辑，而是精确控制字节边界、处理最后一片的长度截断、以及让每个独立文件句柄的生命周期干净收尾——这些地方一错，输出就不可靠。
