TCP长连接不应加应用层重传，因内核已实现完整可靠传输机制；盲目重传会导致重复、错序和状态不一致，仅在协议要求“至少一次送达”且服务端幂等时才可引入。
不能在 TCP 长连接里加应用层重传，除非协议明确要求“至少一次送达”且服务端已实现幂等性——否则只会制造重复、错序和状态不一致。
为什么 TCP 连接上盲目重传会出事
TCP 协议栈本身已完整实现丢包检测、序列号管理、ACK 确认和指数退避重传。Go 的 net.Conn 默认就走这套机制。你在上层再套一层“发完没回就重发”，等于让两套重传逻辑打架：
-
conn.Write()成功只表示数据进了内核发送缓冲区，不代表对方收到；盲目重发会导致接收方收到两条相同消息 - 两次重发内容若不同（比如时间戳/随机数变化），服务端按序列号拼接就会错乱
- 服务端已处理成功并返回响应，但客户端因 ACK 延迟超时而重发，造成订单重复扣款、WebSocket 消息重复渲染
怎么判断是不是真丢包，而不是假死
网卡丢包无法被 Go 应用层直接感知，只能通过间接信号推断。最轻量、最可控的方式是结合业务心跳 + SetReadDeadline：
- 客户端每 30 秒发一次心跳，服务端必须在 5 秒内回
"pong" - 每次读心跳前都调用
conn.SetReadDeadline(time.Now().Add(5 * time.Second))，否则超时只生效一次 - 若
err是net.Error且Timeout()为 true，大概率是中间链路丢包或设备拦截，不是连接断开 - 别依赖
KeepAlive：默认 2 小时才探测一次，且无法反映应用层通路是否可用
UDP 场景下必须自己搞重传，但得避开几个坑
UDP 没有连接、没有 ACK、没有重传，所谓“长连接”只是应用层维护的会话状态。此时丢包只能靠你自己补，但常见错误包括：
-
WriteTo返回nil错误 ≠ 消息送达；它只代表数据进了内核队列，对方收不到也不会通知你 - 高频发包时，每个消息都起一个
time.After+ goroutine，会造成 goroutine 泄漏和调度压力；应改用单个time.Ticker或最小堆统一驱动重传任务 - MTU 超限导致静默丢包：UDP 包 >1500 字节会被 IP 层分片，任一片丢失整包就被内核丢弃；建议应用层限制单包 ≤1200 字节
- 不要对每个
WriteTo都设SetWriteDeadline，它控制的是拷贝进内核队列的耗时，不是网络往返，设太短（如 5ms）容易误判失败
真正难的不是写重传逻辑，而是决定什么时候不该重传——比如非幂等操作、无状态请求、下游未承诺至少一次语义时，重传就是 bug 的源头。
