Go处理大规模并发IO等待的关键是用SetReadDeadline控制底层socket超时、context.Context协调整体生命周期、避免goroutine泄漏；HTTP中http.Server.ReadTimeout不覆盖body阶段，而SetReadDeadline直接作用于net.Conn的Read()调用，更底层有效。
Go 处理大规模并发请求下的网络 IO 等待，关键不是“避免等待”，而是让等待不阻塞调度、不耗尽资源、不泄漏 goroutine。核心是：用 net.Conn 的 deadline 控制单次 IO 超时，用 context.Context 协调整条请求生命周期，同时确保 goroutine 不因等待而堆积。
为什么 SetReadDeadline 比 context.WithTimeout 更底层有效
HTTP 请求中，http.Server.ReadTimeout 只管请求头读取；body 传输阶段仍可能卡住。此时 SetReadDeadline 直接作用于 net.Conn 底层 socket，对 Read() 调用生效，无中间抽象损耗。
- 每次处理新连接前必须调用
conn.SetReadDeadline和conn.SetWriteDeadline，否则长连接可能永久 hang 住 - deadline 时间应动态计算（如
time.Now().Add(30 * time.Second)），不能复用旧时间值 - 超时错误类型为
*net.OpError，用os.IsTimeout(err)判断，而非字符串匹配 - 不要在 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 - 务必在 goroutine 退出前调用
cancel()，否则 context 树无法释放，内存持续增长
高并发下连接数暴涨时的缓冲区优化
每秒几千连接时，bufio.NewReader(conn) 频繁分配会触发 GC 尖峰，表现为周期性延迟毛刺。
- 用
sync.Pool复用bufio.Reader和bufio.Writer实例 - Pool 的
New函数必须返回已初始化对象，例如：return bufio.NewReaderSize(nil, 4096) - 每次从 Pool 获取后，调用
reader.Reset(conn)重置底层 reader，不能直接复用未 reset 的实例 - 不要把
bufio.Reader存入全局 map 或长期持有 —— Pool 对象可能被 GC 回收，导致 panic
真正难的不是设 deadline 或起 goroutine，而是理解：每个连接的生命周期必须有明确的起点、超时点和终点。一旦某个环节（比如响应体读取、日志写入、下游调用）没绑定到统一的 context 或没设 deadline，它就可能成为 goroutine 堆积的源头。
