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() 时，错误类型直接暴露底层问题：
立即学习“go语言免费学习笔记（深入）”；
-
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。常见误判是：
- 把
resp.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 如果触发全链路重试，可能比原始错误更伤。
