Go TCP 连接成功但读写一直超时怎么查

TCP 连接成功只说明连接建立阶段完成，不保证应用已经收到完整请求或会及时返回响应。Go 读写持续超时时，先确认失败发生在 Write 还是 Read，再检查连接上是否遗留过期 deadline、请求是否真正发出、双方是否认可同一种消息边界。记录已处理字节数，才能区分“完全没有响应”和“响应只收到一部分”。

Go 网络库官方文档：https://pkg.go.dev/net

影响面：连接建立不等于业务响应

下面以一个假设故障说明排查过程：客户端连接服务成功，第一笔请求正常，连接复用后却频繁读超时。这个场景用于解释原因分类，不是本文声称已处理的线上事故，也没有虚构故障时长或受影响用户数。

拨号阶段、协议交互和应用处理分别有自己的完成条件。端口可连接不能证明协议正确；本地 Write 成功也不能证明对端已经执行了业务。若服务需要 TLS 或其他握手，直接向其发送普通明文协议，同样不能根据 TCP 成功推断后续一定可用。

时间线：记录拨号、写入和读取阶段

先为一次交换记录连接标识、拨号耗时、请求大小、写入字节数、读取字节数、失败阶段、deadline 的设置时刻和绝对值。业务内容可能敏感，通常只记录长度与关联标识即可，避免把完整报文写入日志。

这些是排查方向而非诊断结果。只有本地信息时，无法确认远端是否已提交操作；要结合服务端关联日志与协议中的确认机制。

触发条件：排查过期截止时间和协议等待

SetDeadline 使用绝对时间，并同时影响读和写。它作用于当前等待及未来 I/O，而不是只作用于紧接着的一次调用。第一次操作之后不更新，连接复用就可能继续使用已经过去的时间。SetReadDeadline 与 SetWriteDeadline 分别控制相应方向。

可以把连接状态看成 TCP 连接、读截止时间和写截止时间三部分；协议状态包括请求帧、响应帧和缓冲写入。读截止时间关联响应读取，写截止时间关联请求发送，缓冲写入则决定请求有没有交给底层连接。图示表达静态责任，不代表抓取到了网络报文。

另一个常见触发条件是双方互相等：客户端等响应，服务端等换行、长度指定的剩余字节或明确的请求结束标识。TCP 没有应用消息边界，单次 Read 不承诺返回一个完整消息。如果使用 bufio.Writer，还要检查 Flush 的错误；写进用户态缓冲区不等于已经写进连接。

根因：区分本地超时与对端状态

确认是连接 deadline 到期时，可用 errors.Is 检查 os.ErrDeadlineExceeded。net.Error 的 Timeout 方法能识别更宽泛的超时类别，但它返回真不必然说明你设置的 deadline 到期。保留原始错误链和操作阶段，别只匹配错误字符串。

DialContext 的上下文控制建连；建连成功后，它的过期不会自动取消返回连接上的后续读写。需要给 I/O 明确设置期限，或者由连接所有者实现取消后关闭连接等策略。不要把拨号预算误当成整笔业务预算。

过期 deadline 可以通过设置未来时间恢复，也可以用零时间清除，但这只恢复等待能力，不代表半包、未确认请求或协议状态已经恢复。只清除期限后把连接放回池里，可能让下一笔请求读到上一笔残留响应。

修复动作：给独立连接设置完整交换预算

以下原创函数演示一个明确的协议：请求与响应都使用四字节大端长度头，正文最多一 MiB。服务端必须实现完全相同的协议；它不是可以向任意端口发送的通用探测器。函数独占新连接，拨号最多两秒，建连后整次读写共享调用方给定的预算。超时或其他错误时关闭连接，不复用未确认的协议状态。

package framedclient

import (
    "encoding/binary"
    "errors"
    "fmt"
    "io"
    "net"
    "os"
    "time"
)

func exchangeError(stage string, n int, err error) error {
    // 保留错误链，调用方仍可用 errors.Is 或 errors.As 分类。
    if errors.Is(err, os.ErrDeadlineExceeded) {
        return fmt.Errorf("%s deadline after %d bytes: %w", stage, n, err)
    }
    return fmt.Errorf("%s after %d bytes: %w", stage, n, err)
}

func writeAll(c net.Conn, data []byte) (int, error) {
    total := 0
    for len(data) > 0 {
        n, err := c.Write(data)
        total += n
        data = data[n:] // 即使同时返回错误，也保留已写入计数。
        if err != nil {
            return total, err
        }
        if n == 0 {
            return total, io.ErrNoProgress
        }
    }
    return total, nil
}

func Exchange(addr string, body []byte, budget time.Duration) ([]byte, error) {
    const maxFrame = 1  maxFrame {
        return nil, fmt.Errorf("invalid budget or request size")
    }
    c, err := net.DialTimeout("tcp", addr, 2*time.Second)
    if err != nil {
        return nil, fmt.Errorf("dial: %w", err)
    }
    defer c.Close() // 独占连接，一次交换结束即释放。

    if err := c.SetDeadline(time.Now().Add(budget)); err != nil {
        return nil, fmt.Errorf("set deadline: %w", err)
    }
    packet := make([]byte, 4+len(body))
    binary.BigEndian.PutUint32(packet[:4], uint32(len(body)))
    copy(packet[4:], body)
    if n, err := writeAll(c, packet); err != nil {
        return nil, exchangeError("write frame", n, err)
    }

    var header [4]byte
    if n, err := io.ReadFull(c, header[:]); err != nil {
        return nil, exchangeError("read header", n, err)
    }
    size := binary.BigEndian.Uint32(header[:])
    if size > maxFrame {
        return nil, fmt.Errorf("response frame too large: %d", size)
    }
    reply := make([]byte, int(size))
    if n, err := io.ReadFull(c, reply); err != nil {
        return nil, exchangeError("read body", n, err)
    }
    return reply, nil
}

代码没有在每次收到数据后延长期限，因此它实现的是交换总预算，不是滑动空闲超时。若协议需要空闲超时，应在明确的成功进展后更新期限，同时保留总预算，避免慢速对端无限拖延。长连接场景应按协议完成状态与连接所有权另行设计，而不是直接删除示例里的 Close。

长度头与响应正文分别读取，错误中也分别计数；正文错误里的字节数不包含已经读完的长度头。io.ReadFull 解决的是固定长度读取，不能修正写错的长度，更不能替代最大长度限制。示例未在本机连接服务执行，不附伪造输出。

防复发：规定连接所有权和重试边界

给每条连接确定一个协议协调者，统一管理截止时间、帧读取、连接池归还和失败关闭。net.Conn 支持多个 goroutine 调用方法，但这不代表多个请求可以无协议协调地交叉读写。另一个 goroutine 更新 deadline 会改变同一连接的期限。

图中的协议协调者管理 TCP 连接、截止时间和帧解析；请求标识与重试策略属于业务恢复责任。重试策略需要参考请求标识与协议确认结果，不能只根据本地超时决定重发。

重试前判断操作是否幂等、远端是否可能已执行、是否有去重标识。写超时可能伴随部分写入，读超时也可能发生在服务端执行成功之后；对有副作用的操作，重新连接后原样重发可能造成重复提交。

把超时加长就能修复吗？它可能改变等待结果，但不能修正过期时间复用或协议死等。先找到等待条件，再选择合理预算。

清除 deadline 后能继续用连接吗？只有确认协议状态仍一致、剩余数据和对端行为可处理时才考虑。否则关闭连接通常更容易保证下一笔交换不被污染。

为什么连上后写入成功仍读不到？写入完成不等于业务响应完成。检查缓冲刷新、握手、帧长度以及远端处理日志，再判断网络或应用原因。