需启用tcp keepalive或应用层心跳探测僵尸连接：调用setkeepalive(true)和setkeepaliveperiod()，或在协议中加入ping/pong帧并配合setreaddeadline()；仅setdeadline()无法识别失联连接。
go net.Conn 怎么检测并关闭僵尸连接
Go 的 net.Conn 本身不自动探测对端是否宕机或网络已断，TCP 连接可能长期处于“半开”状态（SYN_SENT、ESTABLISHED 但对端无响应），表现为读不到数据、写不报错、conn.Read() 卡住 —— 这就是典型的僵尸连接。
不能只靠 SetDeadline() 或 SetReadDeadline()，因为它们只控制单次 I/O 超时，而心跳缺失、对端静默崩溃这类问题需要持续探测。
- 必须启用 TCP keepalive：用
conn.(*net.TCPConn).SetKeepAlive(true)+SetKeepAlivePeriod()（Go 1.19+ 支持），否则内核默认 2 小时不发探针 - 应用层心跳更可靠：在业务协议中插入 ping/pong 帧，配合
SetReadDeadline()检查响应延迟，超时即断连 - 避免在
Read()阻塞时才设 deadline：应在每次读前重置，例如conn.SetReadDeadline(time.Now().Add(30 * time.Second)) - 注意
SetKeepAlivePeriod()最小值受系统限制（linux 默认 min 1s，但实际生效可能 ≥60s，需调/proc/sys/net/ipv4/tcp_keepalive_time）
为什么 conn.SetDeadline 不足以应对网络分区
SetDeadline() 只保证「本次 Read/Write 调用最多等多久」，它不感知连接是否还通。网络分区发生后，如果对端突然下线，本端 TCP 状态仍为 ESTABLISHED，Write() 可能成功（数据进发送缓冲区），Read() 则永远阻塞或等到超时后返回 io.EOF 或 net.OpError —— 但这时已经晚了。
- 分区期间，
Write()成功不代表包到达对端；Read()超时也不代表连接断开，只是本次没读到数据 - 仅靠
SetDeadline()容易误判：比如慢业务请求耗时 25s，设 30s deadline 就会掩盖真实故障 - 真正要踢出的不是“慢连接”，而是“失联连接”，必须结合保活机制或主动心跳
如何用 context.WithTimeout 包裹 accept 循环防 accept 阻塞
服务启动后，listener.Accept() 本身也会阻塞，若底层文件描述符异常（如被信号中断、fd 耗尽），可能卡死整个 goroutine。这不是连接超时问题，而是 accept 层面的可靠性缺口。
立即学习“go语言免费学习笔记（深入）”；
- 不要直接
for conn := range listener.Accept()，改用for { conn, err := listener.Accept(); ... }并加 context 控制 - 用
context.WithTimeout(ctx, 5*time.Second)包裹Accept()调用，超时后重试，避免永久 hang 住 - 错误判断要区分：
err == nil正常；errors.Is(err, os.ErrDeadlineExceeded)可忽略；errors.Is(err, syscall.EINTR)应重试；其他错误（如"accept: too many open files"）需记录并降级
心跳帧设计和超时阈值怎么定才不容易误踢
心跳不是越密越好。太频繁增加无效流量，太宽松又起不到作用。关键是让心跳周期 明显短于 TCP keepalive 探测间隔，并预留至少一倍容错窗口。
- 推荐心跳间隔 15–30s，服务端读超时设为 2× 心跳间隔（如 45s），连续 2 次未收到 pong 才断连
- 心跳消息必须是应用层协议的一部分（如 websocket 的
PingMessage，或自定义{"type":"ping"}），不能只靠 TCP keepalive - 别在
Write()后立刻Read()等 pong：要用独立 goroutine 处理读，主流程继续业务逻辑，否则会串行阻塞 - 注意 NAT 超时：某些家用路由器会 30–60s 清空空闲连接映射，心跳间隔必须小于该值，否则中间设备先断链
最麻烦的其实是“半死不活”的中间状态：连接没断、心跳没丢、但业务包一直发不出去。这种只能靠写超时 + SetWriteDeadline() 配合重试策略兜底，而且得小心别把重试包堆满 socket 缓冲区。