如何在 Go 中处理大规模并发请求下的网络 IO 等待

Go 处理大规模并发请求下的网络 IO 等待，核心其实不是去“消灭等待”——那根本不现实——而是要保证等待本身不会拖垮调度、不会吃光系统资源、更不会让 goroutine 有去无回。做到这一点，靠的是三样东西：用 net.Conn 的 deadline 给单次 IO 划好红线，用 context.Context 给整条请求链路定好生命周期，再加上对 goroutine 泄漏的高度警惕。

先说说为什么 SetReadDeadline 往往比 context.WithTimeout 更管用。HTTP 场景里，http.Server.ReadTimeout 这个配置其实是“只读头，不读身”——它只管到请求头读完为止，body 阶段的读取完全可以卡住不动。而 SetReadDeadline 是直接在底层 socket 上设限，Read() 调用一到时间就报错，没有任何中间层帮你“翻译”超时信号，直截了当。

但这里有几个容易踩的坑：

• 每次处理新连接之前，必须显式调用 conn.SetReadDeadline 和 conn.SetWriteDeadline。别指望一次设置管永久——长连接下如果不重置，某个连接可能就那么挂在那儿，谁也察觉不到。
• deadline 的值应当是动态计算的，比如 time.Now().Add(30 * time.Second)。千万不能把同一个时间对象反复用，否则第二次设置可能直接就过期了。
• 超时错误的类型是 *net.OpError，判断时用 os.IsTimeout(err) 最稳妥，别去匹配字符串——一方面不优雅，另一方面不同 Go 版本的报错文本可能不一样。
• 在 handler 里头反复调用 SetReadDeadline 也是个常见误区。HTTP/1.1 开了 keep-alive 后，一次设置就已经覆盖了整个连接的生命周期，多调反而可能引发竞争。

接下来聊一个让不少人头疼的问题：goroutine 泄漏。最常见的场景就是客户端断开连接后，io.Copy 还在那傻等。它既不认 context.Context，也不会主动检查连接是不是已经死了。怎么修？

• 一个替代方案是用 io.CopyN 配合 select 循环，手动监听 ctx.Done()。这样至少能在超时或取消时主动退出。
• 如果是写 HTTP 服务，直接用 http.TimeoutHandler 把 handler 包一层就好——它会在超时后主动关闭 response writer，算是官方提供的“防呆”方案。
• 自定义 TCP server 时，建议在 handleConn 一开头就创建带 cancel 的 context：ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)。之后所有 IO 操作前都加一句 select { case <-ctx.Done(): ... }，确保能被统一取消。
• 还有一点非常容易被忽略：goroutine 退出前必须调用 cancel()。否则 context 树一直挂着，内存只会越吃越多。

最后说说连接数暴涨时的缓冲区优化。每秒进来几千个新连接，意味着每秒都在分配 bufio.NewReader(conn)——GC 会被逼出尖峰，具体表现就是周期性的延迟毛刺。这时候可以让 sync.Pool 上场。

• Pool 的 New 函数必须返回一个已经初始化好的对象，比如 return bufio.NewReaderSize(nil, 4096)。
• 每次从 Pool 取出来后，别忘了调 reader.Reset(conn) 把底层 reader 重置到新的连接上。直接复用未 reset 的实例，读到的是上一个连接残留的数据。
• 千万别把 bufio.Reader 放到全局 map 里长期持有——Pool 里的对象随时可能被 GC 回收，那样一来 map 里存的引用就会变成一个空指针，用着用着就 panic 了。

说到底，真正考验功力的地方不是设几个 deadline、起几个 goroutine，而是你能不能为每一个连接画出一条清晰的轨迹——从哪里开始，什么时候该超时，最终在哪里结束。只要某个环节（比如响应体读取、日志写入、下游 RPC 调用）没有被统一的 context 约束，或者没有设 deadline，它就可能成为 goroutine 堆积的源头。而一旦堆积起来，再想定位就难了。