应通过类型断言检查错误是否实现net.Error接口并调用Timeout()方法判断超时，而非字符串匹配；context.DeadlineExceeded需用errors.Is单独判断，二者来源不同、处理策略各异。
检查错误是否实现了 net.Error 并调用 Timeout()
Go 中没有统一的“超时错误类型”，不能靠 err.Error() 里含 “timeout” 字符串来判断——不同系统、驱动、协议返回文案不一致，极易误判。真正可靠的方式是类型断言 + 接口方法调用：net.Error 是标准接口，Timeout() 方法才表示该错误与超时相关。
常见错误现象：HTTP 请求返回 net/http: request canceled (Client.Timeout exceeded while awaiting headers)，但你用 strings.Contains(err.Error(), "timeout") 判断失败；或数据库连接超时被误认为网络不可达。
正确做法：
- 先做类型断言：
if netErr, ok := err.(net.Error); ok && netErr.Timeout() { /* 是超时 */ } - 注意：context 超时（如
context.DeadlineExceeded）不实现net.Error，必须额外用errors.Is(err, context.DeadlineExceeded)判断 - 对
*net.OpError（常见于net.Dial、http.Transport抛出的错误），其Timeout()返回值已聚合了底层 syscall 超时逻辑，无需再深入OpError.Err
区分 context.DeadlineExceeded 和底层 I/O 超时
这两个都叫“超时”，但来源和含义完全不同，处理策略也应不同：context.DeadlineExceeded 表示整个请求生命周期被上层主动终止；而 net.Error.Timeout() 表示某次具体 I/O（如 Dial、Read、Write）在内核层面超时返回。
立即学习“go语言免费学习笔记（深入）”；
使用场景：
-
context.DeadlineExceeded多见于http.Client.Do()或db.QueryContext()等支持 context 的高层 API，说明你设的context.WithTimeout生效了 -
net.Error.Timeout()更常见于自定义net.Conn操作（如手写 TCP 客户端）、或 Transport 层日志中，说明连接建立、读响应头等某个环节卡死 - 若两者同时出现（比如
errors.Is(err, context.DeadlineExceeded)为 true，且err又能断言为net.Error），说明 context 超时触发时，底层正阻塞在某个 I/O 上
排查 http.Client 各阶段是否漏设超时参数
只设 client.Timeout 是最常见盲区——它只覆盖“从拨号到响应体读完”的全周期，但无法拦截 DNS 解析慢、TLS 握手卡住、服务端写了 header 却迟迟不发 body 等中间环节。这些漏掉的点，错误仍会表现为超时，但归因位置完全不同。
实操建议：
- 禁用
client.Timeout（设为0），改用http.Transport显式控制各阶段：DialContext（建连+DNS）、TLSHandshakeTimeout、ResponseHeaderTimeout - 例如：若错误频繁出现在
net/http: request canceled (Client.Timeout exceeded while awaiting headers)，大概率是ResponseHeaderTimeout缺失或设得太长 - 抓包验证：用
tcpdump -i any port 443观察是否真有 SYN/ACK 交互，还是卡在 DNS 或 TLS 阶段
确认 SetReadDeadline 是否被重复使用或遗漏
net.Conn.SetReadDeadline 是一次性生效的——只影响下一次 Read 调用。很多人设一次就以为“这个连接从此有超时”，结果后续 Read 全部无保护，遇到对端不发 FIN、中间设备静默丢包时直接 hang 死。
容易踩的坑：
- 用
bufio.Reader包装连接后，在循环读取时忘记每次Read前重设 deadline - HTTP/1.1 keep-alive 连接复用时，handler 内部手动调
conn.SetReadDeadline无效——标准库已接管 I/O，应改用context.WithTimeout+http.TimeoutHandler - 在 goroutine 中启动读操作，但没把 deadline 设置和读操作放在同一 goroutine 内，导致 deadline 设置被其他并发读覆盖
复杂点在于：超时控制不是“设一次就完事”，而是要和 I/O 模式严格对齐——同步阻塞读需每次设，异步或基于 context 的调用则由 runtime 自动注入。漏掉任意一层，定位时就会发现“明明写了超时，怎么还卡住”。
