os.ReadFile会让goroutine阻塞，因其底层调用同步read(2)系统调用，导致goroutine挂起等待磁盘I/O完成，Go运行时不在此时调度其他goroutine；并发读文件时CPU低、耗时接近串行，strace可验证read调用是否真正并发。
os.ReadFile 为什么会让 goroutine 阻塞
它底层调用的是同步系统调用（如 read），哪怕跑在 goroutine 里，也会让该 goroutine 挂起等待磁盘 I/O 完成。Go 运行时不在此时调度其他 goroutine——这不是“可调度的阻塞”，而是内核级阻塞。
常见现象包括：启动 100 个 goroutine 并发读文件，CPU 使用率却很低，整体耗时接近串行；strace -e trace=read,openat 可确认是否真有并发系统调用发出。
-
os.ReadFile适合小文件（ - 大文件或高吞吐场景下必须换策略，否则只是把阻塞从主线程挪到一堆 goroutine 上
- 仅靠
go func() { os.ReadFile() }()不能解决本质问题
bufio.Reader 分块读比 os.ReadFile 更可控
用 os.Open + bufio.Reader 替代 os.ReadFile，能主动控制缓冲区大小、读取节奏，并支持超时和取消。
示例代码中，bufio.NewReaderSize(f, 64*1024) 设置 64KB 缓冲，r.Read(buf) 每次只读 4KB，避免一次性加载整文件进内存。
立即学习“go语言免费学习笔记（深入）”；
- 适合流式处理日志、CSV、JSON Lines 等格式
- 配合
context.WithTimeout在r.Read前设超时，但超时后必须显式调用f.Close()，否则 fd 泄漏 - 别用
bufio.Scanner处理超长行（默认 64KB 限制），改用r.ReadBytes('\n')或自定义分隔逻辑
大文件并发读要分片+限流，不能无脑开 goroutine
直接为每个文件启一个 goroutine 并发读，容易耗尽文件句柄或内存。真正有效的并发是：按偏移分片 + 控制 goroutine 数量 + 复用缓冲区。
例如，一个 10GB 日志文件可按 100MB 切成 100 段，用带缓冲 channel（如 make(chan struct{}, 10)）控制最多 10 个 goroutine 同时工作。
- 用
file.Seek(offset, io.SeekStart)定位分片起始位置 - 每个 goroutine 自己
os.Open并io.ReadFull读取固定长度，避免越界 - 用
sync.Pool复用[]byte缓冲切片，降低 GC 压力 - 别忘了
defer f.Close()，且确保错误路径也关闭
mmap 不是万能解药，只适合特定随机访问场景
syscall.Mmap 或 golang.org/x/exp/mmap 把文件映射到内存地址空间，绕过拷贝，但只在满足以下条件时才值得用：
- 文件较大（>几 MB）且需频繁随机读（如数据库索引、配置查找）
- 读多写少，且不依赖文件锁或原子写语义
- 内存充足，能承受映射开销（映射本身不立即分配物理页，但访问时会触发缺页中断）
- 避免映射超大文件（如 >1GB），否则可能触发 OOM 或 swap
顺序读大文件时，mmap 通常不如分块 read + bufio 稳定；而追加写日志等场景，O_APPEND 标志比 mmap 更可靠。
