Go无真正的异步文件I/O，os.ReadFile本质是同步read(2)系统调用，会阻塞OS线程；在HTTP handler中使用会导致M线程耗尽、QPS断崖下跌，须预加载静态资源、分块读大文件、动态内容优先走网络Body。
go 里没有真正的异步文件 i/o，os.readfile 这类调用本质仍是同步 read(2) 系统调用，会阻塞 os 线程——所谓“异步网络编程”无法掩盖这个事实。想靠加 go 前缀或换 goroutine 就绕过内核阻塞，只会让问题更隐蔽。
为什么 os.ReadFile 在 HTTP handler 里特别危险
它不是“慢”，而是把 goroutine 所在的 OS 线程钉死在内核态等磁盘响应；即使调度器腾挪其他 goroutine，M（线程）数很快耗尽，QPS 断崖下跌，pprof 显示大量 goroutine 卡在 syscall.Read。
- 本地 SSD 延迟约 100μs，但机械盘或 NFS 可达 10ms+；若 handler 平均耗时 5ms，其中 3ms 花在
os.ReadFile，吞吐直接砍掉 60% -
go func() { os.ReadFile(...) }只是把阻塞从主 goroutine 搬到后台，仍占 M、仍吃 fd、仍可能堆积 - strace -e trace=read,openat 会看到大量
read()是顺序执行，而非并发发出
静态资源必须预加载进内存
HTML 模板、JSON 配置、TLS 证书这类不常变的文件，绝不能在每次请求时读——启动时一次性加载，后续 handler 直接用全局变量或 sync.Once 初始化的缓存。
- 用
sync.Once+ 全局[]byte或template.Template，避免重复解析开销 - 若配置需热更新，改用
fsnotify监听变更后 reload，而不是每次请求都os.Stat+os.ReadFile - 别信 “小文件没事” —— 高频小文件读（如每请求查一次模板存在性）会压垮
stat系统调用队列
动态小文件优先走网络 Body，而非本地磁盘
用户上传的 JSON 配置、表单附件等，应直接从 http.Request.Body 读，用 io.ReadAll 或 json.NewDecoder(r.Body)；它走的是内核 socket 缓冲区，不受磁盘 I/O 影响。
- 禁用
r.MultipartReader()后再手动os.Create写临时文件——这是典型反模式，把网络流又拖回磁盘阻塞路径 - 必须落盘时，至少用
os.OpenFile(..., os.O_CREATE|os.O_WRONLY|os.O_TRUNC)+bufio.NewWriterSize(w, 32*1024)，并显式Flush() - 大文件上传（>10MB）要配
context.WithTimeout和http.MaxBytesReader，防恶意长连接耗尽 fd
真要读大文件？分块 + 超时 + 显式 Close
报表导出、日志归档等场景无法规避本地文件读，此时唯一可控方式是拆成小块、设超时、及时释放资源。
- 用
os.Open+bufio.NewReaderSize(f, 64*1024)，再循环r.Read(buf)，别用bufio.Scanner（默认 64KB 行限制易 panic） - 每次
r.Read前套context.WithTimeout，超时后必须f.Close()，否则 fd 泄漏 - 缓冲区
buf建议从sync.Pool获取，避免高频 GC；buf := pool.Get().([]byte)+defer pool.Put(buf)
最易被忽略的一点：goroutine 是用户态调度单元，而磁盘 I/O 的阻塞发生在内核态。Go 运行时能帮你换线程，但换不了内核的调度逻辑——所有“规避”本质上都是移出关键路径，而非消灭阻塞本身。
