UDP丢包主因是内核接收缓冲区过小，需按业务特征估算最小值，建议起步4–8MB，并在bind前设置且验证生效。
UDP 丢包不是网络层问题，而是应用层缓冲、调度和处理节奏没对齐——尤其在弹幕这种短连接+突发流量场景下，ReadFrom 阻塞、net.UDPConn.SetReadBuffer 不够、goroutine 消费不及时，三者叠加直接导致内核接收队列溢出。
UDP接收缓冲区必须显式调大，且不能只设一次
Linux 默认 UDP 接收缓冲区通常只有 212992 字节，千级并发弹幕连接下，几毫秒突发就填满。内核一旦丢包，用户态完全无感知，ReadFrom 返回的 n 会突然变小甚至为 0，但错误码仍是 nil。
- Accept 后立刻调用
conn.(*net.UDPConn).SetReadBuffer(4 * 1024 * 1024)，别依赖系统默认值 - 若用
net.ListenUDP直接监听，必须在ListenUDP前用net.ListenConfig{Control: ...}设置SO_RCVBUF，否则SetReadBuffer可能被内核拒绝（权限不足或已绑定） - 不要设过大（如 64MB），会抢占内核内存，影响其他服务；4MB 是多数弹幕系统的安全上限
ReadFrom 必须非阻塞 + goroutine 分流，不能裸循环
弹幕流量高度不均匀，单个 ReadFrom 调用若卡住（比如 GC 或锁竞争），整个 goroutine 就停摆，后续包全进丢弃队列。
- 用
conn.SetReadDeadline(time.Now().Add(10 * time.Millisecond))替代无限阻塞，超时后立即重试 - 每个 UDP 连接（或每组连接）配独立 goroutine，但别每个包都起一个：用固定 worker 数量（如
runtime.NumCPU()）从 channel 消费解包后的弹幕数据 - channel 必须带缓冲（如
make(chan []byte, 10000)），否则生产者（ReadFrom）一卡，整个接收链就死锁
丢包重传（NACK）和 FEC 必须按频道粒度启用，不能全局开关
实时弹幕对端到端延迟敏感，全局开启 FEC 会增加编码开销和首包延迟；而 NACK 若无收敛机制，反而引发风暴重传。
- FEC 编码只对高价值频道（如主会场、付费直播间）开启，且限制最大冗余包比例 ≤ 15%，避免带宽翻倍
- NACK 请求必须带时间窗口（如最近 200ms 内的序列号），过期请求直接丢弃，防止旧请求触发新重传
- 重传包走独立 UDP socket（
net.DialUDP），不复用接收 socket，避免干扰主接收路径的 deadline 和 buffer 状态
sync.Pool 复用弹幕 buffer，但注意 reset 时机
高频弹幕下，每秒数万次 make([]byte, 1500) 会快速触发 GC，且新分配的 slice 底层内存可能不在 CPU cache line 内，读写更慢。
- 定义
var packetPool = sync.Pool{New: func() interface{} { return make([]byte, 1500) }}，1500 是典型 MTU 下限 - 每次
ReadFrom后，用buf[:n]切片传递数据，归还前执行buf = buf[:0]清空长度（不是nil），否则下次 Get 可能拿到脏数据 - 切忌在 handler 中直接
append到池化 buffer 上——这会悄悄扩容，导致底层内存泄露；先 copy 到新 slice 再处理
真正难调的不是单点参数，而是 buffer 大小、worker 数量、FEC 开启阈值这三者的耦合关系——它们共同决定“突发流量进来时，系统是排队等处理，还是直接丢包”。上线前必须用真实弹幕压测工具模拟峰值流量，观察 netstat -s | grep -i "packet receive errors" 和 Go pprof 的 runtime.netpoll goroutine 数量变化趋势，这两项才是丢包是否被根治的铁证。
