Go 的 net.Conn 默认不启用 TCP KeepAlive，需通过 net.Dialer.KeepAlive（客户端）或 net.ListenConfig.KeepAlive（服务端）显式设置正数秒值来开启；其仅探测底层链路断开，不能替代应用层心跳和读写超时。
Go 的 net.Conn 默认不启用 TCP KeepAlive
Go 标准库的 net.Conn（比如 net.TCPConn）在建立连接后，不会自动开启操作系统层面的 TCP KeepAlive 机制。这意味着即使对端异常断开（如进程崩溃、网络中断、防火墙静默丢包），本端连接仍会维持在 ESTABLISHED 状态，直到应用层尝试读写时才可能发现错误——这往往滞后几十秒到几分钟，甚至更久。
常见现象：服务端 goroutine 卡在 conn.Read() 或 conn.Write()，连接数缓慢上涨，ss -tn | grep :PORT 显示大量 “ESTABLISHED” 但无实际通信的连接。
- Go 1.11+ 起，
net.Dialer和net.ListenConfig支持显式配置 KeepAlive - 默认值为 0，即禁用；需手动设为正数（单位：秒），才会触发内核发送探测包
- KeepAlive 开启后，由内核负责探测，Go 层无需轮询或定时器
net.Dialer.KeepAlive 控制客户端连接探针间隔
客户端发起连接时，通过 net.Dialer 设置 KeepAlive 字段，控制首次探测前的空闲等待时间（即 TCP 的 tcp_keepalive_time）。
示例：
立即学习“go语言免费学习笔记（深入）”；
dialer := &net.Dialer{
KeepAlive: 30 * time.Second,
Timeout: 5 * time.Second,
}
conn, err := dialer.Dial("tcp", "127.0.0.1:8080")
- 设为
30s表示：连接空闲满 30 秒后，内核开始发送第一个 KeepAlive 探测包 - 后续探测间隔和失败重试次数由操作系统决定（Linux 默认：间隔 75s，最多 9 次失败后断连）
- 若设为负值（如
-1），则完全禁用；设为 0 表示使用系统默认值（通常为 2 小时，太长） - 注意：
KeepAlive不影响连接建立阶段，只作用于已建立且空闲的连接
net.ListenConfig.KeepAlive 控制服务端连接探针间隔
服务端监听时，需用 net.ListenConfig 替代直接调用 net.Listen，才能为每个新接受的连接设置 KeepAlive。
示例：
立即学习“go语言免费学习笔记（深入）”；
lc := net.ListenConfig{
KeepAlive: 45 * time.Second,
}
ln, err := lc.Listen(context.Background(), "tcp", ":8080")
if err != nil {
log.Fatal(err)
}
- 该配置仅对后续
ln.Accept()返回的net.Conn生效，不影响监听 socket 本身 - 与客户端不同：服务端无法通过
SetKeepAlive方法动态修改（因为net.Conn接口未暴露该方法），必须在 Accept 前由 ListenConfig 统一设定 - 若服务端连接量大，建议 KeepAlive 时间略长于客户端（如 45s vs 30s），避免因两端探测节奏错位导致误判
KeepAlive 不等于应用层心跳，也不能替代业务超时
TCP KeepAlive 只能发现底层链路断开，无法感知对端进程僵死但 TCP 连接仍被维持的情况（例如对方 goroutine panic 后未关闭连接，但内核仍维持 socket）。此时 KeepAlive 探测成功，连接“活着”，但业务已不可用。
- KeepAlive 是 OS 层机制，粒度粗（秒级）、不可靠（依赖内核参数和网络路径支持）
- 关键业务必须叠加应用层心跳（如定期
Writeping 消息 +Read超时控制） -
SetReadDeadline和SetWriteDeadline仍是必备手段，KeepAlive 仅作为兜底清理手段 - 某些容器环境或云负载均衡器（如 AWS NLB）会重置或忽略 KeepAlive 包，此时必须依赖应用层保活
真正要解决死连接，KeepAlive 是必要但不充分的条件；漏掉应用层超时或心跳，再短的 KeepAlive 间隔也救不了业务逻辑卡住的连接。
