TCP长连接中不能盲目加应用层重传，因其会与TCP内置的丢包检测、序列号管理、ACK确认和指数退避重传机制冲突，易导致重复数据、序列错乱和状态不一致；仅当业务协议明确要求“至少一次送达”且具备幂等性保障时才可谨慎引入。
网卡丢包本身无法被 Go 应用层直接感知，必须通过超时、连接中断或 ACK 缺失等间接信号来推断；应用层重传只应在协议设计允许的前提下做，不能无条件覆盖 TCP 自身重传逻辑。
为什么不能在 TCP 长连接里盲目加应用层重传
TCP 协议栈已内置丢包检测、序列号管理、ACK 确认和指数退避重传。Go 的 net.Conn 默认就走这一套。如果你在上层再封装一次“发完没回就重发”，极易造成：重复数据（接收方未去重）、序列错乱（两次重发内容不一致）、状态不一致（服务端已处理但客户端认为失败）。
常见错误现象包括：用户收到两条相同消息、订单创建接口被重复扣款、WebSocket 消息乱序渲染。
- 仅当业务协议明确要求“至少一次送达”且具备幂等性保障时，才考虑应用层重传
- 不要对
conn.Write()成功就认为对方收到了——它只表示数据进了内核发送缓冲区 - 真正可靠的判断依据是：读取响应、心跳 ACK、或自定义业务级确认包
如何用 SetReadDeadline 和心跳识别真实丢包
TCP 连接空闲时，网卡丢包可能表现为“连接没断，但后续读不到任何数据”。这时靠 SetReadDeadline 是最轻量、最可控的探测方式。
示例场景：客户端每 30 秒发一次心跳，服务端必须在 5 秒内回一个 "pong"：
conn.SetReadDeadline(time.Now().Add(5 * time.Second))
buf := make([]byte, 128)
n, err := conn.Read(buf)
if err != nil {
if netErr, ok := err.(net.Error); ok && netErr.Timeout() {
// 很可能发生了丢包或中间设备拦截，触发重连或告警
log.Warn("heartbeat timeout, possible packet loss")
}
}
- 务必每次读操作前都调用
SetReadDeadline，否则超时只生效一次 - 不要依赖
KeepAlive选项替代业务心跳——它的默认间隔太长（2 小时），且无法反映应用层通路是否可用 - 若心跳超时频繁发生，应先检查网络路径（如
mtr）、防火墙策略或中间代理（如 Nginx 的proxy_read_timeout）
UDP 长连接场景下必须自己实现重传
UDP 没有连接概念，也没有 ACK 机制，所谓“UDP 长连接”其实是应用层维护的会话状态。此时丢包只能靠你自己补。
核心组件缺一不可：
- 每个包带唯一
seq字段（建议 uint64，避免回绕） - 发送方启动 goroutine +
time.AfterFunc管理单次重传定时器 - 接收方收到后立即回一个
ACK:seq=123，并缓存已收seq防重放 - 重试上限建议 ≤3 次，间隔用指数退避（如 200ms → 400ms → 800ms）+ 随机抖动（±50ms）
注意：conn.ReadFromUDP 是阻塞调用，多个并发重传共享同一 *net.UDPConn 会导致读冲突，必须用 channel 或 mutex 控制读取节奏。
真正影响可靠性的常被忽略点
很多团队花大量精力写重传逻辑，却忽略了更底层的瓶颈：网卡接收缓冲区溢出、内核 socket 队列堆积、Go runtime 的 goroutine 调度延迟。
比如你设置了 5 秒超时，但服务端因 GC STW 或协程积压导致响应延迟了 6 秒——这根本不是丢包，而是应用自身吞吐不足。此时加重传只会让问题更糟。
验证手段很简单：
- 用
ss -i查看 socket 的rcv_space和retrans计数 - 在关键路径打时间戳日志，区分“网络耗时”和“处理耗时”
- 对高敏感链路（如支付通知），宁可降低并发、增大缓冲区，也不要盲目堆重试
