udp丢包主因是应用层缓冲与处理节奏失配：接收端缓冲区溢出或goroutine消费不及时占90%，需在conn.accept后立即调用setreadbuffer(4mb)，配合worker池异步处理、so_reuseport与gomaxprocs协同调优，并严格控制nack/fec延迟。
UDP丢包不是网络层问题，而是应用层缓冲、调度和处理节奏没对齐——90%的弹幕系统丢包发生在接收端缓冲区溢出或goroutine消费不及时，而非链路本身。
UDP接收缓冲区被内核丢包
Linux默认net.core.rmem_default约212KB，千级并发弹幕连接下，单个UDPConn未显式调大读缓冲，突发流量直接触发socket receive buffer overflow，内核静默丢弃数据包。
- 必须在
conn.Accept后立即调用conn.SetReadBuffer(4 * 1024 * 1024)（4MB），避免内核队列满 - 不要依赖
sysctl全局调大——不同连接负载差异大，统一值易浪费内存或仍不足 - 验证是否生效：
ss -uln | grep :端口号看Recv-Q是否长期接近上限；若持续>90%，说明缓冲仍不够或消费太慢
goroutine处理RTP/弹幕包时阻塞或延迟
弹幕协议常基于RTP或自定义二进制帧，但很多实现把handleRTPPacket逻辑写在ReadFrom goroutine里，一旦解析、DB写入、广播推送等操作耗时波动，后续包就在缓冲区堆积，最终被新包覆盖。
- 接收goroutine只做最轻动作：拷贝有效数据到预分配
[]byte，然后发给worker池——别做任何IO或计算 - 用
sync.Pool管理弹幕解析上下文对象，避免每次新建struct导致GC压力 - worker池大小建议设为
runtime.NumCPU() * 2，避免过载；超时任务直接丢弃，不阻塞队列 - 检查
pprof中runtime.netpoll状态goroutine数量：若持续>500且不下降，说明worker消费跟不上
SO_REUSEPORT未匹配GOMAXPROCS导致accept瓶颈
弹幕服务常部署多实例监听同一端口，但若启用SO_REUSEPORT却未同步设置runtime.GOMAXPROCS(runtime.NumCPU())，会导致多个listener goroutine被调度到同一个P上，实际仍串行accept，ListenOverflows飙升。
- 启动时强制设置：
runtime.GOMAXPROCS(runtime.NumCPU())，确保每个CPU核心有独立P运行listener - 用
net.ListenConfig{Control: func(fd uintptr) { syscall.SetsockoptInt32(int(fd), syscall.SOL_SOCKET, syscall.SO_REUSEPORT, 1) }}启用复用 - 压测时用
ss -s观察listen_overflows字段：>0即说明accept队列持续溢出，需检查GOMAXPROCS或worker吞吐
丢包重传（NACK）与FEC引入额外延迟
实时弹幕对端到端延迟敏感（理想≤400ms），但盲目开启FEC或NACK会放大抖动——尤其当NACK响应未设超时、FEC冗余包抢占带宽时，反而造成更多丢包。
- NACK只对关键帧或高优先级弹幕启用，普通弹幕不做重传；NACK请求超时严格设为
50ms，超时即放弃 - FEC按组编码（如每10包生成2个冗余包），不跨组混合；冗余包TTL设为
200ms，过期直接丢弃 - 所有重传/冗余逻辑必须走独立goroutine + 有界channel（容量≤1000），防止反压到主接收流
- 线上务必监控
nack_sent/fec_recovered指标：若恢复率
真正卡住弹幕系统的从来不是UDP丢包率，而是接收、分发、渲染三端节奏失配——缓冲区、goroutine池、重传策略这三处参数必须根据实际QPS和平均包大小联合压测校准，离线调参毫无意义。
