TCP长连接不应加应用层重传，因内核已实现完整可靠传输机制；盲目重传会导致重复、错序和状态不一致，仅在协议要求“至少一次送达”且服务端幂等时才可引入。

不能在 TCP 长连接里加应用层重传，除非协议明确要求“至少一次送达”且服务端已实现幂等性——否则只会制造重复、错序和状态不一致。

为什么 TCP 连接上盲目重传会出事

TCP 协议栈本身已完整实现丢包检测、序列号管理、ACK 确认和指数退避重传。Go 的 net.Conn 默认就走这套机制。你在上层再套一层“发完没回就重发”，等于让两套重传逻辑打架：

• conn.Write() 成功只表示数据进了内核发送缓冲区，不代表对方收到；盲目重发会导致接收方收到两条相同消息
• 两次重发内容若不同（比如时间戳/随机数变化），服务端按序列号拼接就会错乱
• 服务端已处理成功并返回响应，但客户端因 ACK 延迟超时而重发，造成订单重复扣款、WebSocket 消息重复渲染

怎么判断是不是真丢包，而不是假死

网卡丢包无法被 Go 应用层直接感知，只能通过间接信号推断。最轻量、最可控的方式是结合业务心跳 + SetReadDeadline：

使用Go语言搭建家庭相册系统-相关课件

使用Go语言搭建家庭相册系统-相关课件

下载

• 客户端每 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 的源头。