磁盘I/O阻塞会拖垮Go服务，因同步系统调用卡住P导致调度停滞；os.ReadFile在HTTP handler中直接使用会使协程挂起，需改用os.Open+bufio.Reader分块读并集成context超时控制。
Go服务里磁盘I/O阻塞会直接拖垮网络协程，不是因为goroutine“写慢了”，而是它卡在系统调用上，让整个P（OS线程）无法调度其他goroutine——哪怕你有1000个处理HTTP请求的goroutine，只要其中几个在等read或write完成，其余的就得干等。
为什么os.ReadFile会让HTTP协程变卡
os.ReadFile底层走的是同步read系统调用，一旦触发，当前goroutine挂起，且Go运行时不认为这是“可调度阻塞”，不会切走。如果你在HTTP handler里直接调用它，那个handler对应的goroutine就停在那儿，直到文件读完；而Go默认每个P最多跑一个系统调用，这个P就被占死了。
- 现象：QPS骤降、/debug/pprof/goroutine?debug=2里大量goroutine卡在
runtime.gopark+syscall.Syscall或internal/poll.(*FD).Read - 验证：用
strace -p $PID -e trace=read,write,openat看是否真有大量串行read调用，而不是并发发出 - 别信“我用了goroutine包一层”：go func() { os.ReadFile(...) }()只是把阻塞换了个goroutine，没解决根本问题
用os.Open + bufio.Reader分块读替代
真正可控的方式是自己管理fd和缓冲区，把大文件读取变成可中断、可限速、可超时的流式操作。
- 必须显式
defer f.Close()，否则fd泄漏比内存泄漏更快拖垮服务 - 缓冲区大小建议64KB~1MB：
bufio.NewReaderSize(f, 65536)，太小导致系统调用频繁，太大浪费内存 - 每次
r.Read(buf)前应检查ctx.Err()，超时后立即f.Close()，不然fd一直挂着 - 避免
bufio.Scanner：默认64KB单行限制，遇到超长日志或JSON Line会panic；改用r.ReadBytes('\n')或r.ReadString('\n')
goroutine数量失控导致文件系统级阻塞
高并发场景下，成百上千goroutine同时os.Open小文件，会迅速打满ext4/xfs的inode缓存和dentry哈希表，内核层面开始变慢——这时连openat都开始延迟，所有I/O协程集体排队。
- 表现：
too many open files错误还没出现，但strace里openat耗时从微秒涨到毫秒级 - 解法：加限流，用
semaphore.NewWeighted(10)（golang.org/x/sync/semaphore）控制最大并发打开数 - 更稳做法：预热+复用fd，对只读配置文件/模板等，
os.Open一次后全局复用，别每次handler都开 - 注意：
ulimit -n设太低会加剧问题，但设太高（如100w）可能触发内核OOM Killer
别碰syscall.Read或unix.Read去“异步”
Go官方不提供真正的异步文件I/O接口。用golang.org/x/sys/unix.Read或裸syscall.Read不仅不能绕过阻塞，反而跳过了Go运行时对fd的封装管理，容易造成fd泄漏、epoll注册丢失、甚至调度器混乱。
- 它仍是同步系统调用，只是绕开了
os.File的封装，没解决本质问题 - 无法和
context集成，超时只能靠setsockopt配SO_RCVTIMEO，对普通文件无效 - 真正需要近似异步的场景（如NFS挂载点读取），优先考虑用
exec.Command("cat", path)走管道，让OS负责调度，但得评估安全与开销
最常被忽略的一点：磁盘I/O阻塞往往不是单个函数的问题，而是整个I/O路径缺乏超时、重试、限流、错误传播的闭环设计。一个没ctx的os.Open，配上没容量限制的channel，再混进HTTP handler，三者叠加，服务就不是“慢”，而是“随机失联”。
