Go os.File.ReadAt 如何控制并发文件

要把一个大文件拆给多个 goroutine 读取，优先用 os.File.ReadAt：每个任务拿到自己的字节偏移和缓冲区，不依赖共享文件游标。这样可以避免多个 goroutine 交替 Seek、Read 时互相改位置；但它不会自动替你限制并发，也不会替你消化短读和 EOF。

按偏移拆分任务，别让 goroutine 共享游标

Read 的位置来自文件当前偏移，调用前后还可能需要配合 Seek。多个 goroutine 如果围绕这个游标工作，代码即使加了锁，也会把“移动位置”和“读取数据”绑成一组临界区，维护成本更高。ReadAt 直接接收 off int64，一次调用只描述“从哪里读多少字节”。Go 官方文档也说明，File 的方法可以并发使用，但操作数量仍受操作系统和设备能力限制。

因此分片时先固定每块的 offset 和 size，再为每块创建独立缓冲区。最后一块不足标准大小时，缓冲区应按实际长度创建，而不是先读满再猜测尾部内容。文件在读取期间如果会被其他进程修改，分片边界之外还要考虑文件版本一致性；ReadAt 本身不提供快照。

让并发度受控，缓冲区和结果各归各位

“File 支持并发”不等于“goroutine 可以无限增加”。磁盘、网络文件系统、文件描述符和内存都会形成实际上限。下面的核心写法用带容量的信号量控制同时进入 ReadAt 的任务数，并让每个任务独占一个缓冲区；示例只展示组织方式，不把示例结果伪装成实测性能。

type part struct {
	offset int64
	size   int
}

func readParts(f *os.File, parts []part, workers int) ([]byte, error) {
	if workers 

生产代码还应在创建 goroutine 前确认每个分片的 size 非负，并在所有读取任务结束后再 Close 文件。若业务允许返回部分结果，可以把每片的错误和字节数一起放入结果对象，而不是只保留一个 firstErr。

短读、EOF 和文件关闭是三个不同问题

ReadAt 返回的是“读到的字节数”和错误。官方约定是：当 n 时必须有非空错误，文件末尾通常表现为 io.EOF。所以不要只写 if err != nil，也不要只看 n。完整分片应满足 n == len(buf)；如果允许最后一片自然截断，就要把它设计成特殊分片，并明确后续解析只使用 buf[:n]。

另一个容易混淆的点是关闭时机。读取任务仍在运行时关闭文件，会让尚未完成的调用失败；正确边界是先等待全部任务，再关闭文件。若需要取消，标准库的 ReadAt 没有 context 参数，应由任务调度层停止派发、记录错误并等待已进入系统调用的任务返回。

ReadAt、Read 和 ReaderAt 到底怎么选

这不是谁“更快”的固定结论，而是访问模型的选择。顺序扫描单个文件时，单协程 Read 通常更直接；需要随机读取或并发读取不连续区间时，ReadAt 能把偏移写进任务本身；需要让实现可替换时，可以把参数收窄为 io.ReaderAt，让文件、内存读取器或测试替身遵守同一个接口。

相关问题

ReadAt 会改变文件当前偏移吗？

它按参数里的偏移读取，不应依赖或改写顺序读取所使用的游标；需要顺序游标时仍应选择 Read。

ReadAt 返回 EOF 但数据已经读满，算失败吗？

判断时先看 n 是否等于缓冲区长度。完整读取和短读的处理策略不同，不能把所有 EOF 都当成同一种失败。

并发数应该设置多大？

从较小的 worker 数开始，用实际设备和业务指标调整；不要把 goroutine 数直接当成磁盘并行能力。