怎么判断 net.Error 是超时还是连接断开
Go 的网络错误不是简单用 err == io.EOF 或字符串匹配就能稳判的，因为 io.EOF 只在读取完成时显式返回，而真实场景中 TCP 连接中断、服务端关闭、客户端提前断连，往往表现为带超时信息的 net.OpError，且其底层 Err 字段可能为 syscall.ECONNRESET、io.EOF，甚至 nil。
正确做法是类型断言到 net.Error，再看 Timeout() 和 Temporary()：
if netErr, ok := err.(net.Error); ok {
if netErr.Timeout() {
// 真正的超时：如 DialTimeout、Read/Write deadline 超出
}
if !netErr.Temporary() {
// 很可能是连接已断（如 RST）、不可重试
}
}
-
Timeout()返回true才代表「时间到了」，不是所有含 "timeout" 字样的错误都算——比如"i/o timeout"是典型，但"use of closed network connection"不是 -
Temporary()为false通常意味着连接已处于失效状态（如对端发了 FIN/RST），此时重试无意义 - 不要直接比较
err == io.EOF来判断连接关闭：HTTP/1.1 keep-alive 下，服务端主动关闭连接时，客户端Read可能返回io.EOF；但更多时候是read: connection reset by peer这类系统级错误
HTTP 客户端里怎么区分 context.DeadlineExceeded 和底层网络超时
HTTP 请求失败时，错误可能是 context.DeadlineExceeded（上下文超时），也可能是底层 net.Conn 的 Read/Write deadline 触发的 net.OpError。二者语义不同，处理策略也该不同。
context.DeadlineExceeded 是你在调用前设的总时限（比如 http.Client.Timeout = 5s），它不关心底层发生了什么；而 net.OpError 是 socket 层真实发生的阻塞超时（比如 DNS 解析卡住、TLS 握手慢、首字节迟迟不来）。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 如果错误是
context.DeadlineExceeded，说明整个请求生命周期已超限，不应重试（除非你明确做了指数退避+重置 context） - 如果错误是
net.Error且Timeout() == true，但context.Err() == nil，说明是 transport 层某一步单独超时（如Transport.DialContext耗太久），可考虑调整DialTimeout或KeepAlive参数 - HTTP/2 场景下，
context.DeadlineExceeded还可能掩盖真实的流级错误（如stream error: stream ID x; REFUSED_STREAM），需开启http.Transport.ForceAttemptHTTP2 = true并配合 debug 日志观察
io.EOF 在 TCP 连接中到底意味着什么
io.EOF 在 Go 网络编程里常被误读为“对方关闭了连接”，但它其实只表示「对端已关闭写入，且本端已读完所有剩余数据」。它本身不携带连接状态信息，也不等于连接已断。
比如一个 HTTP/1.1 服务端发送完响应后调用 conn.CloseWrite()，客户端 Read 到末尾就会得 io.EOF；但如果服务端直接 conn.Close()（即 RST），客户端更可能收到 read: connection reset by peer，而不是 io.EOF。
-
io.EOF是合法终端信号，适合做 clean shutdown 判断，但不能用来触发重连逻辑 - 若想确认连接是否还活着，得靠
conn.SetReadDeadline+ 尝试Read一个字节，或监听conn.RemoteAddr()是否仍有效（注意：断连后该值不会变，不可靠） - 在长连接池（如
http.Transport）中，io.EOF会被自动回收连接；但若底层是syscall.ECONNABORTED，连接会被标记为 broken 并丢弃
为什么 errors.Is(err, context.DeadlineExceeded) 有时不生效
因为 HTTP client 默认会把底层错误包装成 *url.Error，再包一层 *http.httpError，最终导致原始 context 错误被藏在多层 Unwrap() 之后。直接 errors.Is(err, context.DeadlineExceeded) 会失败。
必须用 errors.Is 配合递归展开，或改用 errors.As 提取最内层 context 错误：
var ctxErr context.Context
if errors.As(err, &ctxErr) && ctxErr.Err() == context.DeadlineExceeded {
// 成功捕获
}
- Go 1.20+ 推荐用
errors.Is(err, context.DeadlineExceeded)—— 它内部已支持跨包装器匹配，但前提是各中间层用了fmt.Errorf("...: %w", err)正确包装 - 如果你自己封装了 transport 或 dialer，忘了用
%w，那errors.Is就会失效 - 第三方库（如某些 gRPC 客户端）可能用字符串拼接替代错误包装，此时只能靠
strings.Contains(err.Error(), "deadline exceeded")应急，但稳定性差
真正难处理的从来不是单个错误类型，而是同一现象在不同协议层、不同 Go 版本、不同操作系统上呈现为完全不同的错误值——别信文档里的“应该”，永远用 fmt.Printf("%+v", err) 看一眼实际结构。
