os.ReadFile 会阻塞 goroutine 因其底层调用同步系统调用，导致 goroutine 挂起且不可调度；适合小文件低频场景，大文件应改用 os.Open + bufio.Reader 分块读或 mmap 随机访问。
为什么 os.ReadFile 会阻塞整个 goroutine
它底层调用的是同步系统调用（如 read），即使在 goroutine 中调用，也会让该 goroutine 挂起等待磁盘 I/O 完成。Go 运行时不会为此切换其他 goroutine——因为这不是“可调度的阻塞”，而是系统级阻塞。
常见现象：启动 100 个 goroutine 并发读文件，但 CPU 使用率低、整体耗时接近串行，说明大量 goroutine 在等 I/O，没真正并发。
- 仅靠
go func() { os.ReadFile(...) }()不能解决 I/O 阻塞，只是把阻塞挪到另一个 goroutine，数量一多照样积压 -
os.ReadFile适合小文件、低频、对延迟不敏感的场景；大文件或高吞吐场景下必须换策略 - Linux 上可通过
strace -e trace=read,openat观察是否真有并发系统调用发出
用 io.ReadFull + os.Open 配合 bufio.Reader 控制读取节奏
主动控制缓冲区和读取粒度，避免一次性加载大文件进内存，也便于结合 context 实现超时或取消。
f, _ := os.Open("huge.log")
defer f.Close()
r := bufio.NewReaderSize(f, 64*1024) // 64KB 缓冲
buf := make([]byte, 4096)
for {
n, err := r.Read(buf)
if n > 0 {
// 处理 buf[:n]
}
if err == io.EOF {
break
}
if err != nil {
// handle error
break
}
}
- 比
os.ReadFile内存友好，尤其适合流式处理日志、CSV、JSON Lines 等 - 可配合
context.WithTimeout在r.Read前设超时（注意：超时后需显式f.Close()，否则 fd 泄漏） - 不要用
bufio.Scanner处理超长行（默认 64KB 限制），改用ReadBytes('\n')或自定义分隔符逻辑
真正异步：用 syscall.Read + runtime.Entersyscall？不，用 golang.org/x/sys/unix 的 Read 也不行
Go 官方不提供真正的异步文件 I/O 接口（不像 Windows 的 IOCP 或 Linux 的 io_uring）。unix.Read 仍是同步阻塞调用，且绕过 Go 运行时的 fd 管理，容易出问题。
立即学习“go语言免费学习笔记（深入）”；
目前最实用的“伪异步”路径是：
- 对普通文件：用 goroutine +
os.Open+ 分块读 +sync.Pool复用缓冲区（降低 GC 压力） - 对网络文件（如 NFS）或慢存储：加
context.WithTimeout和重试逻辑，避免单次卡死拖垮整组任务 - 若必须近似异步：将文件读取委托给外部进程（如
exec.Command("cat", path)），通过管道接收数据，由 OS 负责调度；但引入额外开销和安全风险
什么时候该考虑 mmap：syscall.Mmap vs memmap 库
内存映射适合随机访问大文件（如数据库索引、视频帧提取），避免反复 seek + read；但它不是“异步”，而是把 I/O 延迟到页错误时触发，且仍受缺页中断阻塞影响。
data, _ := syscall.Mmap(int(fd.Fd()), 0, int(size),
syscall.PROT_READ, syscall.MAP_PRIVATE)
// 后续访问 data[i] 可能触发 page fault，此时 goroutine 仍会阻塞
-
syscall.Mmap是低层封装，需手动syscall.Munmap，且跨平台行为差异大（Windows 不支持相同语义） - 更推荐用
github.com/edsrzf/mmap-go，它封装了平台差异并支持Close方法 - mmap 不减少总 I/O 时间，只改变触发时机；若你本就顺序读完整文件，它反而可能因 TLB miss 更慢
tokio-uring）、C++（libaio）或直接上 io_uring 用户态驱动。Go 的强项是“简单并发 + 快速交付”，不是“零拷贝极致吞吐”。别为了异步而异步，先确认瓶颈真在文件读取，而不是解析逻辑或锁竞争。 
