17370845950

Go中net.Conn关闭后读写会返回具体错误而非panic：如“use of closed network connection”“connection reset by peer”等，均属*net.OpError，可通过errors.Is或类型断言区分场景。

Go 中 net.Conn 关闭后继续读写会触发什么错误

调用 conn.Read() 或 conn.Write() 时若连接已关闭（如对端断开、超时关闭、主动 conn.Close()），Go 会返回具体错误而非 panic。最常见的是：

read: connection reset by peer

（Linux）、

read: broken pipe

或

use of closed network connection

（本地主动关连接后还读写）。这些都属于 *net.OpError，可类型断言判断：

• err != nil && errors.Is(err, io.EOF)：对端正常关闭连接（FIN）
• err != nil && errors.Is(err, net.ErrClosed)：本地已调用 conn.Close()
• opErr, ok := err.(*net.OpError); ok && opErr.Err != nil && strings.Contains(opErr.Err.Error(), "broken pipe")：写入时对端已消失

HTTP 服务中如何区分客户端取消和真实请求失败

Go 的 http.Server 默认将客户端提前断开（如浏览器跳转、fetch abort）视为普通错误，日志里常看到

http: abort handler

或

read tcp ...: i/o timeout

。关键不是忽略它，而是别把它当业务异常处理。正确做法是检查 http.Request.Context().Err：

• req.Context().Err == context.Canceled：客户端取消（包括超时、手动 cancel）
• req.Context().Err == context.DeadlineExceeded：服务端设置了 Handler.Timeout 或中间件超时
• 其他非空 req.Context().Err 多为网络层中断，一般无需重试或告警

注意：不要在 handler 里对 context.Canceled 打 ERROR 日志，它高频且非故障。

TCP 连接建立阶段的常见错误及应对

使用 net.Dial() 或 net.Listen() 时，错误类型直接暴露底层问题：

• dial tcp 10.0.0.1:8080: connect: no route to host：路由不可达（非端口问题）
• dial tcp 10.0.0.1:8080: connect: connection refused：目标地址有响应但无监听进程（端口未开/服务未启）
• dial tcp 10.0.0.1:8080: i/o timeout：SYN 发出后没收到 SYN-ACK（防火墙拦截、目标宕机、网络丢包）

重试逻辑必须区分这三类：connection refused 可立即重试（服务可能刚启动）；no route to host 和超时建议退避重试（如指数退避），避免雪崩。

HTTP 客户端如何安全处理 4xx/5xx 响应与连接错误

http.Client.Do() 只在真正无法发起请求（DNS 失败、TLS 握手失败、连接被拒）时返回 error；而 HTTP 状态码如 404、502 都算“成功响应”，resp.StatusCode 非零但 err == nil。常见误判是：

• 把 re

  

  sp.StatusCode >= 400 当作 err != nil 忽略处理
• 没调用 resp.Body.Close() 导致连接无法复用（http.Transport 连接池卡死）
• 对 5xx 盲目重试，但某些 5xx（如 501 Not Implemented）重试无意义

建议统一包装响应检查：

if resp.StatusCode >= 400 {
    defer resp.Body.Close()
    body, _ := io.ReadAll(resp.Body)
    log.Printf("HTTP %d: %s", resp.StatusCode, string(body))
    return fmt.Errorf("HTTP %d", resp.StatusCode)
}

连接级错误（如 Client.Timeout、x509: certificate signed by unknown authority）才走 error 分支，需单独监控。

协议错误本身不复杂，难的是区分哪些该重试、哪些该降级、哪些该静默丢弃——尤其在高并发场景下，一个 connection reset by peer 如果触发全链路重试，可能比原始错误更伤。