Go net.Pipe 怎样区分读写超时和对端关闭

在 Go 测试里，net.Pipe() 很适合模拟一条内存中的全双工连接，但它的读写没有内部缓冲：一端的 Read 要等另一端的 Write，一端关闭也会唤醒另一端的阻塞调用。要区分“等太久”和“对端已经关闭”，核心做法是先设置 deadline，再用错误值判断，而不是只比较错误字符串。

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

判断顺序可以固定为：先用 errors.Is(err, os.ErrDeadlineExceeded) 识别 deadline 超时，再用 errors.Is(err, net.ErrClosed) 识别已经关闭的连接，最后保留原始错误处理其它情况。net.Error.Timeout() 适合作为辅助信号，不应代替具体错误判断。

先理解 net.Pipe 的同步连接边界

net.Pipe() 返回两个实现了 net.Conn 的端点。它们是全双工的，但没有内部缓冲；对端没有配合写入时，读取端可能一直阻塞。因此测试代码不能把一次 Read 当成普通字节切片读取，而应明确安排另一端的写入、关闭或 deadline。

package main

import (
    "fmt"
    "net"
)

func main() {
    left, right := net.Pipe()
    defer left.Close()
    defer right.Close()

    // Pipe 没有内部缓冲，右端写入的数据由左端读取。
    go func() {
        defer right.Close()
        _, _ = right.Write([]byte("ready"))
    }()

    buf := make([]byte, 5)
    n, err := left.Read(buf)
    if err != nil {
        // 测试中保留原始错误，后续才能做 errors.Is 判断。
        fmt.Println("read failed:", err)
        return
    }
    fmt.Println(string(buf[:n]))
}

这里的关键关系是：left.Read 等待 right.Write，而不是等待某个操作系统 socket 缓冲区。若测试只启动读取 goroutine，却没有对端写入或关闭，超时和 goroutine 泄漏就会混在一起。

用读写 deadline 把阻塞变成可判断错误

net.Conn 提供三种相关方法：SetReadDeadline 只影响读，SetWriteDeadline 只影响写，SetDeadline 同时设置两者。deadline 是绝对时间点，会影响已经阻塞和之后发起的 I/O；如果要继续使用连接，需要在未来重新设置 deadline。

func waitForPeer(c net.Conn) error {
    // 绝对时间点只用于本次测试的等待上限。
    if err := c.SetReadDeadline(time.Now().Add(200 * time.Millisecond)); err != nil {
        return fmt.Errorf("set read deadline: %w", err)
    }

    buf := make([]byte, 1)
    // 对端没有写入或关闭时，Read 会在 deadline 到达后返回错误。
    _, err := c.Read(buf)
    return err
}

示例需要导入 time。生产代码通常还要判断设置 deadline 的返回值；测试代码则应在每个会阻塞的读写点设置合适的上限。不要用一个永不过期的 Read 等待对端，因为一旦测试路径提前返回，剩余 goroutine 可能继续占用连接。

用 errors.Is 识别 deadline 超时

Go 官方 net.Conn 文档说明，deadline 到期后，I/O 错误会包装 os.ErrDeadlineExceeded，应使用 errors.Is 判断。错误的具体文本或具体类型可能因实现和包装层变化，不适合做稳定分支。

func classifyReadError(err error) string {
    if err == nil {
        return "成功"
    }

    // deadline 错误可能被包装，使用 errors.Is 保留可兼容的判断方式。
    if errors.Is(err, os.ErrDeadlineExceeded) {
        return "读写超时"
    }

    // 对端或本端已经关闭连接时，优先识别 net.ErrClosed。
    if errors.Is(err, net.ErrClosed) {
        return "连接已关闭"
    }

    // 最后保留原始错误，避免把未知错误误报成超时或关闭。
    return "其它网络错误：" + err.Error()
}

net.Error.Timeout() 可以用来判断错误是否具有超时属性，但它是接口能力，不等于“这次一定是本次设置的 deadline 到期”。网络错误还可能因其它原因报告 timeout，因此在同时掌握哨兵错误时，应优先使用 errors.Is，再把 Timeout() 作为兼容旧实现的补充。

区分对端关闭与其它网络错误

当一端调用 Close 时，另一端被阻塞的读写会被唤醒并返回错误。官方文档把 net.ErrClosed 定义为已关闭连接上的 I/O 错误；这个错误可能被再次包装，所以仍然用 errors.Is。不要看到返回错误就一律当作超时，也不要只用 err.Error() 做字符串包含判断。

func waitOrClose(c net.Conn) string {
    // 先设置 deadline，避免对端既不写也不关时测试无限等待。
    _ = c.SetReadDeadline(time.Now().Add(300 * time.Millisecond))

    buf := make([]byte, 8)
    _, err := c.Read(buf)
    if err == nil {
        return "收到数据"
    }

    // 先判断绝对的 deadline 哨兵错误。
    if errors.Is(err, os.ErrDeadlineExceeded) {
        return "对端未响应，读取超时"
    }
    // 再判断连接关闭，避免把关闭动作记录为超时。
    if errors.Is(err, net.ErrClosed) {
        return "对端或本端已关闭"
    }
    return "读取失败：" + err.Error()
}

如果测试使用的 Go 版本或底层实现返回的是其它关闭错误，保留 err 并结合 errors.Is 检查对应哨兵值；不要为了让断言通过而把所有错误改写成 os.ErrDeadlineExceeded。错误分类的目的是解释测试状态，而不是掩盖真正的失败原因。

常见误区与速查

• net.Pipe 没有内部缓冲；读写两端必须在测试中配合。
• 读写 deadline 是绝对时间点，设置后会影响当前阻塞和后续 I/O。
• 超时优先用 errors.Is 判断，Timeout() 只作为辅助信息。
• 关闭连接要用 errors.Is(err, net.ErrClosed) 识别，并保留其它错误。

只要把“对端没响应”和“连接已关闭”分成两个错误分支，net.Pipe 的测试就不会再靠猜测错误文本。先限制等待时间，再按哨兵错误和原始错误分类，最后在测试收尾阶段关闭两端连接，基本就能覆盖常见的阻塞、超时和关闭场景。

相关问题

SetDeadline 和 SetReadDeadline 有什么区别？

SetDeadline 同时设置读写 deadline；SetReadDeadline 只影响读。只测试单向读时，使用方向明确的读 deadline 更容易避免误伤另一条 I/O 路径。

为什么不直接比较 err.Error()？

错误可能被包装，文本也可能随实现变化。使用 errors.Is 判断哨兵错误，才能在增加上下文后仍保留稳定的程序分支。