Go SetDeadline 为什么会影响后续多次读写

如果一个 net.Conn 在循环开始时调用了 SetDeadline(time.Now().Add(3 * time.Second))，3 秒后并不是“下一次读写”才超时，而是这个连接上的期限已经到点。后续 Read、Write 仍会受到同一个绝对时刻影响，直到重新设置未来的 deadline，或者传入零值清除它。

要控制整条连接的总耗时，可以只设置一次 SetDeadline；要控制每次读写之间的空闲时间，就必须在成功 I/O 后或下一次 I/O 前刷新期限。读写方向不同、共享连接并发使用时，还要避免用一个全局 deadline 互相覆盖。

先把连接上的期限资产看清

排查这类问题时，先把“期限”当成连接状态，而不是某个函数调用的临时参数。net.Conn 的 SetDeadline 同时设置读和写两条方向的 deadline；如果只想限制服务端响应读取，应使用 SetReadDeadline，否则一次写入设置的时间也可能影响后面的读取。

还有一个容易忽略的点：deadline 使用绝对时间。下面的时间点代表连接在墙上时钟到达 10:00:03 后停止等待，不代表每一次 Read 都获得 3 秒。

为什么第二次读写仍然遇到第一次 deadline

典型误用是把一次 deadline 写在循环外：

deadline := time.Now().Add(3 * time.Second)
if err := conn.SetDeadline(deadline); err != nil {
    // 设置失败时不能继续把连接当成可用连接
    return err
}
for {
    n, err := conn.Read(buf)
    if err != nil {
        // 用标准错误判断，而不是只比较字符串
        if errors.Is(err, os.ErrDeadlineExceeded) {
            return fmt.Errorf("读取超时: %w", err)
        }
        return err
    }
    handle(buf[:n])
}

这段代码表达的是“整个循环最多等 3 秒”。如果第一次读取用了 2.8 秒，第二次读取只剩约 0.2 秒；如果第一次读取结束后已经超过 3 秒，第二次就会立刻返回超时。官方接口说明也明确指出，期限适用于所有未来和当前阻塞的 I/O，超时错误会包装 os.ErrDeadlineExceeded。

因此看到“第一次成功、后面连续超时”时，先记录 deadline 的实际时间、每次 I/O 的开始时间和错误类型。不要仅凭 Timeout() 为 true 下结论，因为其他网络错误也可能报告 timeout。

把一次性总预算改成空闲超时

长连接通常关心的是“连续 10 秒没有数据就断开”，这与“从请求开始总共只能用 10 秒”不同。空闲超时的核心是每次成功读写后重新生成一个未来的绝对时间：

func readFrame(conn net.Conn, buf []byte, idle time.Duration) (int, error) {
    // 本次读取只允许等待 idle，不能复用已经过期的旧时间点
    if err := conn.SetReadDeadline(time.Now().Add(idle)); err != nil {
        return 0, err
    }
    n, err := conn.Read(buf)
    if err != nil {
        // 保留原始错误，调用方可以用 errors.Is 识别超时
        return n, err
    }
    return n, nil
}

// 清理阶段传入 zero time，解除遗留的读期限。
_ = conn.SetReadDeadline(time.Time{})

读写方向可以分别刷新：读响应前设置 SetReadDeadline，发送大块数据前设置 SetWriteDeadline。如果业务确实要求每个方向共享同一个总预算，再使用 SetDeadline，但要从同一个请求开始时间计算剩余预算，不能每次都重新加完整时长。

并发连接的防护与复查清单

Conn 允许多个 goroutine 同时调用方法，但 deadline 是同一个连接上的共享状态。一个 goroutine 为写入设置了 2 秒期限，另一个 goroutine 紧接着为读取设置期限，若调用的是 SetDeadline，读写两边都会被覆盖。并发场景应由连接所有者统一管理期限，或分别调用读写方向 API，并把“谁负责刷新、谁负责清除”写进协议。

写超时还可能返回 n > 0，这表示部分数据已经写出。重试前必须根据协议确认已发送的字节，不能把整个缓冲区盲目再发一次。连接关闭时应停止相关 goroutine；关闭会解除阻塞中的读写并返回错误。

• 总耗时：循环外设置一个绝对 deadline，不要把它误当空闲计时器。
• 空闲耗时：每次成功 Read 或 Write 后刷新未来时间。
• 方向隔离：只管读就用 SetReadDeadline，只管写就用 SetWriteDeadline。
• 错误判断：使用 errors.Is(err, os.ErrDeadlineExceeded)，同时记录 n。
• 清理状态：复用连接前确认是否需要用 time.Time{} 清除旧期限。

常见问题

SetDeadline 设置一次后需要每次 Read 都调用吗？

如果要限制整条交互的总时长，不需要；如果要限制每次等待的空闲时间，就需要在每次操作前或成功后刷新。

SetDeadline 会不会只影响下一次 I/O？

不会。它影响所有未来以及当前阻塞的读写，直到期限被更新或清除。

怎样取消 Go 连接超时？

对对应连接或方向传入 time.Time{}。清除前要确认调用方确实不再需要超时保护。

读写并发时应该使用哪个 API？

读写预算独立时分别使用 SetReadDeadline 和 SetWriteDeadline，并由一个明确的连接所有者协调刷新，避免相互覆盖。

把 SetDeadline 看成连接上的绝对截止状态，后续行为就容易预测：总预算只设置一次，空闲预算持续刷新，方向不同就拆开控制，异常路径则保留错误和部分读写量。