go TCP超时需分三步设置：Dial（含DNS和握手）、Read、Write；KeepAlive须显式启用并注意系统参数覆盖；http客户端需自定义Transport配置各层超时，且必须关闭Response.Body。
Go TCP连接超时设置必须分三步：Dial、Read、Write
Go 的 net.Conn 超时不是“设一次就全局生效”，而是三个独立控制点。很多人只调 SetDeadline，结果发请求卡住几十秒才返回——其实是 net.Dial 阶段没设超时，底层阻塞在 DNS 解析或 SYN 重传上。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
net.DialTimeout或&net.Dialer{Timeout: 5 * time.Second}控制建连总耗时（含 DNS + TCP 握手） - 连接建立后，用
conn.SetReadDeadline控制每次Read的等待上限（比如 HTTP 响应头读取） - 同理，
conn.SetWriteDeadline控制Write发送阻塞时间（尤其大包或网络拥塞时） - 注意：
SetDeadline是绝对时间点，需每次读/写前重新设置；SetReadDeadline不影响Write，反之亦然
KeepAlive 参数必须显式配置，标准库默认不开启
Go 标准 net.Conn 创建后，KeepAlive 是关闭状态。这意味着即使中间网络断开（如 NAT 超时、防火墙静默丢包），连接仍显示“活跃”，直到下次读写才报错——可能拖到几分钟后。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 使用
&net.Dialer{KeepAlive: 30 * time.Second}启用并设探测间隔 - 服务端监听时，通过
ln.(*net.TCPListener).SetKeepAlive(true)和SetKeepAlivePeriod设置（Go 1.19+ 支持） - linux 下最终行为还受系统参数影响：
/proc/sys/net/ipv4/tcp_keepalive_time等会截断你的设置 - KeepAlive 探测失败后，连接不会自动关闭，需等下一次
Read/Write才触发read: connection reset by peer类错误
HTTP Client 超时容易漏掉 Transport 层配置
直接改 http.Client.Timeout 只控制整个请求生命周期（从 Dial 到 Body 读完），但无法单独约束连接复用、TLS 握手或空闲连接回收——这会导致连接池里积压大量“半死”连接。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 必须自定义
http.Transport，设置.DialContext（含 Dial 超时）、TLSHandshakeTimeout、IdleConnTimeout、KeepAlive - 例如：
transport := &http.Transport{DialContext: (&net.Dialer{Timeout: 5 * time.Second, KeepAlive: 30 * time.Second}).DialContext} - 别忽略
Response.Body必须被关闭，否则连接无法归还连接池，MaxIdleConnsPerHost会迅速打满 - 若服务端不支持 HTTP/2，
ForceAttemptHTTP2设为false，避免 TLS 协商失败卡住
测试 KeepAlive 是否生效的关键是模拟中间断连
本地 localhost 或直连环境几乎测不出 KeepAlive 效果——因为链路稳定，探测包来回毫秒级，根本触发不了失败逻辑。真实问题只出现在有 NAT、防火墙或移动网络的场景。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
iptables在服务端丢弃特定方向的 ACK 包：iptables -A input -p tcp --tcp-flags ACK ACK -j DROP，再等 KeepAlive 探测超时 - 抓包确认：
tcpdump -i any port <port> and 'tcp[tcpflags] & (tcp-rst|tcp-fin) != 0'</port>看是否发出 FIN/RST - 不要依赖
conn.RemoteAddr().String()判断连接是否还通——它永远返回地址，不校验实际可达性 - 生产环境建议配合应用层心跳（如 HTTP HEAD /health）做双重保障，TCP KeepAlive 本身只防链路静默中断
KeepAlive 的系统级依赖和超时叠加逻辑最容易被跳过：你设了 30 秒探测，但 Linux 默认 tcp_keepalive_time 是 7200 秒，最终生效的是更长的那个值。