os.ReadFile 与 http.Get 延迟差异源于 I/O 类型本质不同：前者为微秒级本地系统调用，后者涉及网络协议栈、TLS 协商等，即使 localhost 也达毫秒级；吞吐与缓冲优化效果亦因场景而异。
Go 中 os.ReadFile 与 http.Get 的延迟来源完全不同
文件 I/O 在本地磁盘上走的是系统调用路径（如 read() 或 pread()），而网络 I/O 要经过 TCP 握手、TLS 协商、内核协议栈、网卡驱动、物理链路等多个环节。哪怕目标服务就在本机（http://localhost:8080），也要走 loopback 接口，受 socket 缓冲区、Nagle 算法、TIME_WAIT 状态等影响。实测中，一次小文件 os.ReadFile("config.json") 通常在微秒级；而同等大小的 http.Get("http://localhost:8080/config") 往往在毫秒级，差两个数量级不是异常，是常态。
阻塞模型下，io.Copy 和 net.Conn.Read 的吞吐表现差异明显
对本地文件使用 io.Copy（底层调用 readv + writev）可轻松达到数百 MB/s；但对 HTTP 响应体做同样操作时，实际吞吐受限于：
• 远端写入速度（比如慢速生成 JSON 流）
• 中间代理或负载均衡器的缓冲策略
• Go 默认的 http.Transport 连接复用行为（MaxIdleConnsPerHost 影响并发连接数）
• TLS 加解密开销（尤其在无硬件加速的容器环境）
若你发现 io.Copy(ioutil.Discard, resp.Body) 比 io.Copy(ioutil.Discard, file) 慢十倍以上，先检查是否启用了 HTTP/2、是否命中了连接池，而不是怀疑代码写法。
bufio.NewReader 对文件和网络流的优化效果不对称
对文件使用 bufio.NewReader 能显著减少系统调用次数，尤其在频繁小读（如逐行解析日志）时收益明显；但对网络流，它只缓存已从 socket 接收但尚未消费的数据，无法规避 RTT 和拥塞控制带来的等待。更关键的是：
• 文件 reader 的缓冲区填满后立即可用
• 网络 reader 的缓冲区可能长期为空，ReadString('\n') 会阻塞直到远端发来数据或超时
• 若远端不按行发送（比如写入未加换行符的二进制块），ReadString 可能永远卡住
所以别默认给 http.Response.Body 包一层 bufio.Reader 就以为“优化”了——得看下游怎么读，以及远端怎么写。
用 pprof 定位真实瓶颈时，syscall.Syscall 和 runtime.netpoll 的占比说明一切
跑一个压测程序，采集 CPU profile：
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30
如果火焰图里大量时间落在
syscall.Syscall（尤其是 read、write），说明是文件 I/O 密集型；如果集中在 runtime.netpoll、internal/poll.runtime_pollWait、crypto/tls.(*Conn).readRecord，那就是网络等待主导。注意：•
os.Open 后立刻 Stat() 是常见误操作，增加一次额外系统调用•
http.Client 默认禁用 keep-alive 时，每个请求都重握手，crypto/tls.(*Conn).Handshake 会高频出现• 使用
io.ReadFull 读固定长度网络包时，若远端写得慢，它会在 netpoll 上反复挂起
立即学习“go语言免费学习笔记（深入）”；
真正拉开性能差距的，往往不是单次操作快慢，而是连接建立、错误重试、超时设置、缓冲区大小这些非核心路径上的决策。别只盯着 Read 函数耗时，先看你的 http.Transport 配置和文件打开方式是否匹配实际场景。
