大文件并发读取必须分块，不能直接用os.readfile；应通过os.stat().size()获取大小后均分offset/length，各goroutine独立os.open并用io.readat读指定区间，严格对齐边界、复用缓冲区、按offset排序合并。
大文件并发读取必须分块，不能直接用 os.ReadFile
直接对 GB 级文件调用 os.ReadFile 并发，等于让每个 goroutine 把整份文件 load 到内存——不仅 OOM 风险极高，GC 压力会瞬间拉满，底层 I/O 仍是串行排队，根本没提速。真正可行的并发读，是手动切偏移、多 goroutine 各读一段。
- 先用
os.Stat().Size()获取总大小，再按块均分 offset 和 length（比如每块 4MB） - 每个 goroutine 必须调用
os.Open单独打开文件，拿到独立的*os.File句柄；共享一个句柄并发io.ReadAt在某些 OS 上会出隐含状态冲突 -
io.ReadAt要求文件支持随机读——普通本地磁盘文件可以，但 NFS、CIFS 或只读挂载可能不支持，得提前试错或 fallback 到流式读 - 块边界必须严格对齐：最后一块长度 =
totalSize - offset，不能硬写固定 size，否则越界返回io.EOF或错乱数据
为什么 io.ReadAt 比 bufio.Scanner 更适合大文件分块
bufio.Scanner 是为逐行处理设计的，内部缓冲不可控，且无法指定读取起始位置；而 io.ReadAt 是纯偏移+长度语义，零拷贝、无额外分配、完全符合分块需求。它不依赖文件当前 offset，天然规避了 Seek 的系统调用开销。
- 别在 goroutine 里反复
make([]byte, blockSize)——用sync.Pool复用缓冲区，尤其当块数 > 100 时效果明显 - 缓冲区大小建议设为 64KB 或 1MB，接近页大小且避开频繁小分配；太小导致 syscall 过多，太大浪费内存
- 读完一块后，结果要带 offset 一起传给下游（比如
struct{ Offset int64; Data []byte }），否则拼接时顺序错乱
并发数不是越多越好，SSD 和 HDD 完全不同
本地 SSD 的队列深度高，并发 8–16 路通常能打满吞吐；但机械硬盘寻道慢，并发超 4 路后 I/O 请求就开始乱序堆积，实际吞吐反而下降。网络文件系统（如 NFS）更敏感，2–4 路就是极限。
- 别用
runtime.NumCPU()直接当并发数——那是 CPU 密集型任务的参考，I/O 密集型要看存储介质 - 用
golang.org/x/sync/semaphore控制最大并发，比裸起 goroutine 更稳；例如sem := semaphore.NewWeighted(8) - 如果文件路径列表里混着大小差异极大的文件，先按
os.Stat().Size()分组：小文件走高并发（如 16 路），大文件单独限 2 路
结果合并必须考虑顺序和内存压力
分块读出来的数据是乱序到达的，但最终拼成完整文件时必须严格按 offset 排序。如果把所有块都 append 到一个 slice 再写，等于又把整个文件 load 进内存——这跟不用分块没区别。
- 推荐做法：用
sync.Map或带锁 map 缓存已读块（key=offset），收到最后一块后按 offset 从小到大遍历写入目标文件 - 更省内存的做法：边读边写——每个块读完立刻
output.WriteAt(data, offset)，但要求目标文件提前Truncate(totalSize)预分配空间，否则元数据频繁更新拖慢速度 - 若需原子写（防中断损坏），先写临时文件，最后
os.Rename；注意 NFS 不保证 rename 原子性，生产环境得加校验
分块读的核心难点从来不在代码怎么写，而在于 offset 边界计算是否精确、文件句柄生命周期是否可控、以及结果落地时如何避免二次内存爆炸——这些地方漏掉一个，再多协程也白搭。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
