netpoll 仅是 Go 运行时对 epoll/kqueue/iocp 的抽象，负责高效监听 socket 事件，不解决广播延迟；压低延迟需批量写、环形缓冲区、禁用 Nagle、复用内存及固定 worker。
netpoll 本身不解决广播延迟，它只是底层 I/O 多路复用器
很多人看到 netpoll 就以为能“自动优化广播”，其实不是。Go 的 netpoll 是 runtime 内部封装的 epoll/kqueue/iocp 抽象层，只负责高效监听 socket 事件（如可读、可写），并不参与业务逻辑调度或消息分发策略。大群聊广播延迟高，根本原因通常是：单连接串行写、未做写缓冲区合并、goroutine 创建泛滥、或 TCP Nagle 算法未关闭。netpoll 只是让这些操作“更少阻塞”，但不会让一次广播从 10ms 变成 1ms。
真正压低广播延迟的关键：批量写 + 无锁环形缓冲区
群聊广播本质是“一对多写”，频繁调用 conn.Write() 会触发多次系统调用和内核拷贝，且每个 write 都可能被 Nagle 或 TCP 延迟确认卡住。实操上必须绕过默认流式写法：
- 为每个连接维护一个
ringBuffer（如github.com/chenzhuoyu/ringbuffer），所有待广播消息先入缓冲区，由独立 goroutine 统一writev批量刷出 - 禁用 Nagle：
conn.SetNoDelay(true)，否则小包会被内核攒批，引入 200ms 级毛刺 - 避免在广播路径中分配新 slice —— 使用
sync.Pool复用[]byte缓冲区，防止 GC 暂停打断广播 goroutine - 不要为每条广播消息起一个 goroutine；改用固定数目的 worker（如
runtime.GOMAXPROCS(1)下配 2–4 个）轮询多个连接的 ringBuffer
为什么用 cloudwego/netpoll 而不是标准 net.Conn？
标准 net.Conn 基于 netpoll，但封装了大量同步抽象（如 Read/Write 阻塞语义），掩盖了底层事件驱动能力。而 cloudwego/netpoll 提供了更直接的接口：
-
LinkBuffer支持零拷贝切片视图，广播时可直接从消息池取 buffer 并 attach 到连接，避免内存复制 -
EventLoop.Runner允许你把广播逻辑注册为非阻塞回调，避免 goroutine 调度开销 - v0.7.0 后
LinkBuffer.Until错误成本降低，对高频小包广播更友好 - 注意：它不兼容
http.Server或grpc.Server，仅适用于自研长连接服务（如 WebSocket 网关、IM 推送层）
容易被忽略的容器与调度陷阱
在 Kubernetes 部署的大群聊服务中，以下两点常导致广播延迟突然升高，且 trace 看不出明显瓶颈：
- 容器 CPU 限制（
--cpus=1）但 Go 默认设GOMAXPROCS=8，导致 P 频繁抢占，广播 goroutine 被挤出 CPU 时间片——必须显式设GOMAXPROCS=1或通过runtime.GOMAXPROCS(int(os.Getenv("CPU_LIMIT")))动态适配 - 集群网络插件（如 Cilium）开启 eBPF 流量整形后，对短连接突发流量限速严格，而广播本质是瞬时 burst；需检查
bpf_lxcmap 中 conntrack 条目是否因广播洪泛被驱逐 - 不要依赖
time.Since()测单次广播耗时——它受 GC 和调度干扰；改用runtime.nanotime()在广播入口/出口打点，并聚合统计 P99
