可靠UDP需在应用层实现ARQ：为数据包分配唯一序列号，接收端用map缓存去重并维护expect_seq，发送端用time.Timer管理重传（支持Stop/Reset），头部须显式编码为大端定长字节流。
UDP本身不保证可靠，必须自己加ACK和重传
Go 的 net.Conn 接口对 UDP 是不适用的——net.UDPConn 只提供原始收发能力，没有连接状态、无序号、无超时、无重传。所谓“可靠 UDP”，本质是应用层在 UDP 之上模拟 TCP 的 ARQ（自动重传请求）逻辑。你不能指望 WriteToUDP 返回错误就代表对方收到了；它只表示数据进了内核发送队列，甚至可能被静默丢弃。
常见错误现象：sendto: no route to host 或 write: broken pipe 是系统级错误，但更多丢包根本无提示；接收端收不到包，发端却毫无感知；多次重传后仍乱序或重复。
- 必须为每个发送的数据段分配唯一序列号（
seq），建议用 uint32 或 uint64，避免回绕歧义 - 接收端需维护滑动窗口（哪怕只是 1 个 slot）来判断是否重复、是否跳号
- 发送端要启动独立 goroutine 管理重传定时器，不能阻塞主逻辑
- ACK 包体极简：通常只需回传
ack_seq和可选的窗口大小，别塞多余字段
用 time.Timer 实现带取消的重传控制，别用 time.Sleep
time.Sleep 在重传场景下是危险的：它无法被外部中断，一旦设了 500ms，就算收到 ACK 也得干等完。而真实网络中，你希望“收到 ACK 就立刻停掉对应定时器”。time.Timer 支持 Stop() 和 Reset()，是唯一合理选择。
使用场景：每发出一个带 seq 的数据包，就创建一个专属 *time.Timer，超时触发重传；收到对应 ack_seq 后立即 timer.Stop()。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 别复用同一个
Timer：多个 seq 共享会导致错停或漏停 - 注意
Timer.Reset()在已触发状态下返回 false，需检查返回值再决定是否新建 - 超时时间建议从 200ms 起步，后续按指数退避（如 200 → 400 → 800），避免突发拥塞
- 重传次数上限设为 3–5 次即可，再失败应通知上层关闭会话，而非无限循环
序列号与 ACK 匹配必须严格按字节解析，别依赖结构体二进制布局
Go 中 struct 的内存对齐、字段顺序、padding 都可能因编译器或平台变化，直接 binary.Write 一个 struct 到 UDP 包里，极易在跨平台或升级 Go 版本后出错。序列号、ACK 标志、负载长度这些关键字段，必须显式编码为定长字节流。
常见错误现象：发送端用 struct{Seq uint32; Flag byte} 打包，接收端解包时发现 Seq 总是 0 或极大值；或者本地测试正常，部署到 ARM 服务器后 ACK 校验全失败。
- 头部统一用大端（network byte order）：用
binary.BigEndian.PutUint32(buf, seq) - 定义固定头部格式，例如前 4 字节是
seq，第 5 字节是 flag（0x01=DATA, 0x02=ACK），第 6–7 字节是 payload length - 接收端先读够最小头长（如 7 字节），校验长度字段再读 payload，避免越界 panic
- 别在包里传指针、slice 或 interface{}——UDP 不支持引用传递
接收端必须做去重和乱序缓存，但别实现完整滑动窗口
纯 Stop-and-Wait（每发一个等一个 ACK）太慢；完全照搬 TCP 的滑动窗口又过度设计。折中做法是：接收端维护一个 map[uint32][]byte 缓存最近收到的未确认包，并用最小期望序号（expect_seq）驱动交付。这不是为了乱序重组，而是防止因 ACK 丢失导致的重复重传污染上层。
性能影响：map 查找 O(1)，但内存不释放会累积；若不做清理，跑几天后 map 占满几百 MB 很常见。
- 缓存只存最近 64 或 128 个 seq（按业务 RTT 估算），老包直接丢弃并回 ACK
- 每次收到新包，先查是否已存在；存在则丢弃，仍回 ACK（这是幂等关键）
- 收到
expect_seq后，连续递增交付，并更新expect_seq；遇到空缺就停，不等待 - 别在 map 里存原始
*net.UDPAddr——地址信息应从ReadFromUDP返回值取，不要序列化进包
最易被忽略的是 ACK 的发送时机：不是每收到一个包都立刻回，而是延迟几毫秒合并（比如收到包后启动一个 5ms 的 time.AfterFunc），否则小包风暴会让重传逻辑更混乱。
