Go net.Conn 设置 Deadline 后为什么后续读写一直超时

Go 的 net.Conn.SetDeadline 设置的是一个绝对截止时刻，不是“下一次读写等待几秒”。这个时刻一旦过去，连接上的后续读写仍会受到影响，所以常见现象就是：第一次读写超时后，后面每次读写都立即返回超时。

官方文档：https://pkg.go.dev/net#Conn

先看清 Deadline 为什么会“粘住”

下面这段逻辑把截止时间设置为“现在之后两秒”。两秒是整个连接阶段共享的绝对时刻，而不是每次 Read 都重新拥有两秒。即使第一次读在截止时间前完成，第二次读也必须赶在同一个时刻之前完成。

deadline := time.Now().Add(2 * time.Second)
if err := conn.SetDeadline(deadline); err != nil {
    // 设置失败时不要继续把连接当成有超时保护的连接使用。
    return fmt.Errorf("设置连接截止时间失败: %w", err)
}

// 这里的截止时刻不会因为一次成功 Read 自动向后滑动。
n, err := conn.Read(buf)
if err != nil {
    // 超时只是错误的一类，连接关闭和网络中断要单独处理。
    if errors.Is(err, os.ErrDeadlineExceeded) {
        return fmt.Errorf("读取超时: %w", err)
    }
    return fmt.Errorf("读取连接失败: %w", err)
}
_ = n

因此，排查“后续读写一直超时”时，第一件事是打印或记录传给 SetDeadline 的时间，而不是继续增大缓冲区。若这个时间已经早于当前时刻，连接后续 I/O 立即失败是符合接口语义的。

总截止时间和空闲超时不是一回事

一次请求、一次协议握手或一段完整传输需要“最晚几点结束”时，使用 SetDeadline 很合适，因为读写共享同一个总预算。若需求是“每次成功读到数据后，允许对端空闲五秒”，就不应在连接建立时只设置一次总 deadline。

把一次性设置改成可滑动的空闲窗口

空闲超时的关键不是把 duration 传给连接，而是在每轮 I/O 前或成功后计算一个新的绝对时间。下面只刷新读方向；如果协议还要求写入不能长时间阻塞，再为写方向设置独立 deadline。

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, fmt.Errorf("刷新读取 deadline 失败: %w", err)
    }

    n, err := conn.Read(buf)
    if err != nil {
        // errors.Is 比比较错误字符串更稳定，也能识别包装后的超时错误。
        if errors.Is(err, os.ErrDeadlineExceeded) {
            return 0, fmt.Errorf("等待下一帧超时: %w", err)
        }
        return 0, fmt.Errorf("读取帧失败: %w", err)
    }
    return n, nil
}

// 需要取消全部读写限制时传入零值，而不是传一个很大的未来时间。
func clearDeadline(conn net.Conn) error {
    return conn.SetDeadline(time.Time{})
}

刷新时机要和协议语义一致：把 deadline 放在“本次 Read 开始前”通常最直观；如果一次成功读入的数据还会触发多步解析，也可以在解析完成后再刷新，但要明确这会把解析耗时纳入还是排除在空闲窗口之外。

排查清单与边界

• 确认使用的是绝对时间，没有把 time.Duration 直接误当作 time.Time。
• 确认是否需要读写共用总预算；不需要时拆成 SetReadDeadline 和 SetWriteDeadline。
• 确认每次设置 deadline 的返回错误被处理，避免误以为限制已经生效。
• 超时后若要复用连接，必须设置一个未来的新时间；若要彻底取消，传入零值。
• Write 即使返回超时，也可能已经写入部分字节，协议层要结合返回的 n 决定是否能重试。

常见问题

SetDeadline 设置一次后会自动延长吗？

不会。它保存的是绝对截止时刻；要实现空闲超时，需在每轮成功或开始下一轮 I/O 时重新设置未来时间。

只想限制读操作，为什么不该继续用 SetDeadline？

SetDeadline 会同时影响读和写。只限制读时使用 SetReadDeadline，可以避免写方向被意外套上同一个时间边界。

怎么取消已经过期的 deadline？

调用 SetDeadline(time.Time{})；它表示读写不再因 deadline 超时。连接本身的关闭、协议错误和其他网络错误仍然有效。