SetReadDeadline和SetWriteDeadline每次I/O前必须重设，Dial和KeepAlive不可忽略，HTTP超时需分层配置；deadline是绝对时间点，不自动续期，不跨操作生效。
SetReadDeadline 必须每次 Read 前重设
很多人以为调一次 SetReadDeadline 就能让后续所有读操作自动超时，结果发现第二次 Read() 依然卡死。这是因为该方法只对「下一次」读生效，用完即失效。
常见错误现象：HTTP 头读完后读 body 卡住、协议包分多次解析时第二段超时失败、用 bufio.Reader 时底层 Read() 没重设 deadline 导致阻塞。
- 每次调用
Read()前都得执行conn.SetReadDeadline(time.Now().Add(5 * time.Second)) - 若用
bufio.Reader，不能只在初始化时设一次；需在每次调用reader.Read()或reader.ReadString()前，手动对conn重设 - 绝对时间点不可复用：传入
time.Now()或已过期的time.Time会立即报net.ErrTimeout - 错误判断要严谨：
if ne, ok := err.(net.Error); ok && ne.Timeout()，别只看err == net.ErrTimeout
Write 超时不是可选，而是必须显式控制
Write() 卡住比 Read() 更隐蔽——它不依赖对方发数据，而可能堵在内核发送缓冲区满、对端接收窗口为 0、或中间网络拥塞。不设写超时，goroutine 会在 Write() 上 hang 几分钟甚至更久。
典型场景：推送服务向弱网设备发大包、RPC 客户端批量写请求体、自定义协议中连续 Write() 多个字段。
- 每次
Write()前调用conn.SetWriteDeadline(time.Now().Add(3 * time.Second)) -
Write()返回n, nil只表示数据进了内核 buffer，不代表送达对端；超时仅约束“进 buffer”这一步的阻塞 - 不要用
SetDeadline()替代分开设置——语义模糊，且读写超时需求通常不同（比如读要 5s，写只要 1s） - 若写的是流式数据（如视频帧），建议按帧/块设独立超时，避免单帧卡住拖垮整条连接
Dial 阶段超时和 KeepAlive 不是可选项
只设 SetReadDeadline 和 SetWriteDeadline，但忽略连接建立阶段，等于没做超时控制。DNS 解析慢、SYN 重传、防火墙拦截都会让 net.Dial() 卡在 30 秒以上，且不触发任何 deadline。
另外，没有 KeepAlive 的长连接，在 NAT 超时或链路静默中断后仍显示“活跃”，直到下次读写才暴露问题，资源滞留严重。
- 用
&net.Dialer{Timeout: 5 * time.Second, KeepAlive: 30 * time.Second}替代net.DialTimeout，获得完整控制权 -
KeepAlive默认关闭，必须显式启用；Linux 下还受/proc/sys/net/ipv4/tcp_keepalive_time等系统参数影响 - 服务端监听时，记得对
*net.TCPListener调用SetKeepAlive(true)和SetKeepAlivePeriod（Go 1.19+） -
KeepAlive探测失败不会自动关连接，仍需靠下一次Read()/Write()触发错误，所以 deadline + keepalive 要配合使用
HTTP Client 超时不能只靠 client.Timeout
http.Client.Timeout 是兜底总耗时，但它掩盖了各环节的真实瓶颈。DNS 卡住、TLS 握手失败、响应头迟迟不来、空闲连接堆积……这些都会导致 goroutine 泄漏或连接池污染，而 Timeout 无法定位问题。
真实线上故障里，80% 的“超时”其实发生在 Transport 层，而非业务逻辑。
- 必须配置
Transport：用DialContext控制建连（含 DNS）、TLSHandshakeTimeout控制握手、ResponseHeaderTimeout防服务端半开 -
IdleConnTimeout和KeepAlive决定连接复用效率，设太大会积压“假活跃”连接，设太小则频繁重连 - 单次请求优先用
context.WithTimeout+http.NewRequestWithContext，确保超时能穿透到底层连接 - 永远记得
resp.Body.Close()，否则连接无法释放回池，IdleConnTimeout形同虚设
真正容易被忽略的点是：deadline 是绝对时间，不是相对时长；它不自动续期，也不跨 I/O 生效；而 Go 的网络超时机制本质是“事件驱动”的——你得主动告诉内核“这次操作我最多等多久”，而不是期待它记住你的偏好。
