tcp长连接不应加应用层重传，因内核已实现可靠传输机制；盲目重传会导致重复、错序和状态不一致，仅在协议要求“至少一次送达”且服务端幂等时才可引入。
TCP长连接里加应用层重传，基本等于主动制造 bug。 它和内核 TCP 栈的重传逻辑打架，不是补漏，是捅漏——重复、错序、状态不一致全由此来。真正该做的，是用心跳 + SetReadDeadline 推断丢包，再靠幂等性和业务语义兜底。
为什么 conn.Write() 成功 ≠ 消息送达
conn.Write() 只表示数据拷贝进了内核发送缓冲区，连网卡都没出。对方是否收到、ACK 是否回来、中间设备是否静默丢包，Go 应用层完全无感。常见错误现象包括：
- 订单接口被重复扣款（服务端已处理并返回 200，客户端因 ACK 延迟超时重发）
- WebSocket 消息渲染两次（客户端未做去重，两次“pong”都触发了 UI 更新）
- gRPC stream 中断后重连，但旧请求响应突然抵达，导致状态错乱
可靠判断依据只有三个：conn.Read() 返回响应、心跳包收到明确 "pong"、或自定义业务级确认包被解析成功。
用 SetReadDeadline + 心跳识别真实丢包
空闲连接下网卡丢包最典型的表征是：连接没断，但后续读不到任何数据。这时 SetReadDeadline 是最轻量、最可控的探测方式。
- 客户端每 30 秒发一次心跳，服务端必须在 5 秒内回
"pong" - 每次调用
conn.Read()前都得重设conn.SetReadDeadline(time.Now().Add(5 * time.Second))，否则超时只生效一次 - 若
err是net.Error且Timeout()为 true，大概率是中间链路丢包或防火墙拦截，不是连接断开 - 别依赖
KeepAlive：默认 2 小时才探测一次，且无法反映应用层通路是否可用
示例代码中漏掉重设 deadline 是高频坑点，一写就错。
UDP 场景下必须自己实现重传，但别踩 goroutine 泄漏
UDP 没有连接、没有 ACK、没有重传，“长连接”只是应用层维护的会话状态。此时丢包只能靠你自己补，但常见错误包括：
-
WriteTo返回nil错误 ≠ 消息送达；它只代表数据进了内核队列，对方收不到也不会通知你 - 高频发包时，每个消息都起一个
time.After+ goroutine，会造成 goroutine 泄漏和调度压力；应改用单个time.Ticker或最小堆统一驱动重传任务 - MTU 超限导致静默丢包：
UDP包 >1500 字节会被 IP 层分片，任一片丢失整包就被内核丢弃；建议应用层限制单包 ≤1200 字节 - 不要对每个
WriteTo都设SetWriteDeadline，它控制的是拷贝进内核队列的耗时，不是网络往返，设太短（如 5ms）容易误判失败
真正难的不是写重传逻辑，而是决定什么时候不该重传——比如非幂等操作、无状态请求、下游未承诺至少一次语义时，重传就是 bug 的源头。
如何从 Go 里拿到真实 TCP 重传次数
net.Conn 不暴露底层状态，但 Linux 的 getsockopt(TCP_INFO) 可读取 tcpi_total_retrans 字段——这才是内核统计的累计重传量。
- 必须对已建立的连接调用，例如在
http.HandlerFunc中通过req.Context().Value(http.LocalAddrContextKey)获取net.Conn，再转换为syscall.Conn - 错误
EINVAL通常意味着连接尚未完成三次握手，或 socket 类型不是AF_INET/SOCK_STREAM - 优先用
unix.TCPInfo而非手写 struct，避免不同内核版本字段偏移差异 - 不要高频轮询：
tcpi_total_retrans是单调递增计数器，两次采样差值才是本次区间重传量
抓不到重传包不是 tcpdump 问题，是重传常发生在内核发送队列中，根本没走到网卡——禁用 GSO/GRO、用 -i any -S 才能看清。
