udp视频流在go中必须实现应用层可靠性机制，否则必然卡顿或黑屏；需分片（≤1200字节）、加序列号与msg_id、ack/nack驱动重传，并设大读缓冲、合理超时及端到端心跳探测。
WriteTo 返回 nil 错误 ≠ 视频帧已送达，UDP 本身不保证投递。想靠 Go 标准库的 net.UDPConn 直接传视频流并指望“不卡、不花屏、不黑屏”，必须补上应用层可靠性机制——这不是优化选项，是底线要求。
为什么 UDP 视频流在 Go 里一跑就卡顿或黑屏
常见现象不是“连接断了”，而是：前端播放器卡住几秒后恢复、画面撕裂、音频不同步、某路摄像头长期无信号但设备在线。这些几乎都指向同一类底层问题：
-
WriteTo调用成功但对方没收到——UDP 写入内核队列即返回，丢包静默发生 - 单包超 MTU（比如发了 1500+ 字节）导致 IP 分片，任一片丢失整包被内核丢弃，
ReadFrom完全收不到 - 接收缓冲区太小（默认几 KB），突发帧率高峰时直接溢出丢包，
SetReadBuffer(4*1024*1024)不是可选，是必设 - 没设
SetReadDeadline或设得太短（如 5ms），局域网里一次超时就中断接收循环，后续包全被跳过
Go 中必须做的三件事：分片、序列号、ACK 驱动重传
不能只靠 conn.WriteTo 往外喷数据。视频帧通常几百 KB，必须切片；每片要带唯一 seq 和 msg_id；接收端按序缓存、缺片触发 NACK 或等重传；发送端维护未确认片集合，用 time.Timer 统一驱动（别每个片起 goroutine）。
- 分片上限建议 ≤1200 字节（留足 IPv4/UDP 头 + 可能的 VXLAN/Geneve 封装空间）
- 序列号用 uint16 足够（65536 片/消息），配合
msg_id区分不同帧，避免跨帧 ACK 混淆 - 重传间隔用指数退避：
50ms * 2^attempt，上限封顶到 1s，避免网络拥塞恶化
别碰 LocalAddr()，也别信日志里的“write success”
conn.LocalAddr() 在容器或 NAT 环境下返回的是监听地址（如 :8080），不是实际出口 IP+端口，拿它拼接 STUN 或打洞会失败。而日志里每行 "wrote 1372 bytes" 只代表拷贝进内核队列，不代表发出、不代表抵达、不代表被解码。
- 真要验证送达，得在应用层加轻量心跳 + 带时间戳的 ACK，例如每 200ms 发一个
type Ping struct { TS int64; Seq uint16 } - 接收端回
Pong{TS: ping.TS, Seq: ping.Seq}，发送端算 RTT 并动态调重传窗口 - 所有日志必须带上下文：是哪路设备、第几帧、第几片、是否重传第几次
真正容易被忽略的，是“静默丢包”没有错误路径可捕获——它既不触发 error，也不进 ReadFrom，更不会让 goroutine panic。你只能靠缺失的序列号、超时未响应的 Pong、或前端主动上报的卡顿事件去反推。这要求你在设计初期就接受：UDP 视频流的“可靠”，永远是概率性的、可观测的、需主动探测的，而不是靠一次 WriteTo 调用来担保的。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
