go 的 netpoller 是单线程轮询器，所有网络事件均由唯一绑定至 m0 线程的 epoll_wait/kqueue 统一处理，无法通过增加 goroutine 数量提升吞吐；so_reuseport 是绕过该瓶颈的内核级方案，需显式配置并配合多进程部署。
Go 的 netpoller 是单线程轮询器，不是多核可伸缩组件 —— 想靠增加 goroutine 数量提升网络事件吞吐，注定失败。
netpoller 为什么只用一个 OS 线程
Go 运行时在启动时调用 netpollinit 初始化唯一一个轮询器实例，绑定到初始的 M0 线程（主 OS 线程）。所有通过 net.Listen 创建的监听 socket、以及后续 Accept 出来的连接 socket，其就绪事件（readable/writable）都由这一个轮询器统一调用 epoll_wait（Linux）或 kqueue（macOS）捕获。
这意味着：
- 即使你启动 100 个 goroutine 调用
http.Serve，也只有一个epoll_wait在跑，CPU 使用集中在单个核心 -
runtime.LockOSThread()对 netpoller 无效：它只能把 goroutine 绑定到某个 M，但轮询器本身不随 goroutine 复制 - goroutine 并发处理业务逻辑（如 JSON 编解码、DB 查询）可以多核并行，但“收包”和“发包准备”环节卡在单点
SO_REUSEPORT 是绕过单轮询器瓶颈的正解
Linux 3.9+ 内核支持 SO_REUSEPORT，允许多个进程（注意：是进程，不是 goroutine）监听同一端口，内核在新连接到达时直接做哈希分发，每个进程各自拥有独立的 netpoller 实例。
实操要点：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 必须用
net.ListenConfig显式设置SO_REUSEPORT，标准net.Listen("tcp", ":8080")不启用它 - Go 1.11+ 才完整支持该配置；低于此版本需用 syscall 手动 setsockopt
- 每个进程应配独立的
GOMAXPROCS（如GOMAXPROCS=4），避免 Goroutine 调度争抢 P - 反向代理（Nginx/HAProxy）或 DNS 轮询只是应用层负载均衡，无法解决单进程 netpoller 瓶颈；SO_REUSEPORT 是内核级分流，更高效
常见错误：误以为 “多 goroutine Serve = 多轮询器”
典型错误代码如下：
<pre class="brush:php;toolbar:false;">for i := 0; i <p>实际行为：</p>
- 首个
ListenAndServe 成功 bind + listen，后续调用立即返回 <code>http: Server closed错误（因端口已被占用） - 错误被忽略后，看似“起了多个服务”，实则只有第一个在工作，其余 goroutine 已退出
- 即使改用不同端口（如 :8080/:8081），若无反向代理或客户端主动轮询，流量仍不会自动分散
什么时候真需要关心 netpoller 底层
绝大多数 HTTP/API 服务无需碰 netpoller 源码，但以下场景需留意：
- 自研网络框架（如基于
net.Conn封装的长连接网关），需理解conn.Read阻塞时实际触发的是netpoll注册与唤醒 - 调试高延迟连接：
netpoll中的netpollBreak用于中断阻塞等待，若频繁触发可能说明事件处理慢于接收速率 - 性能压测中发现单核 CPU 100% 且
epoll_wait占比极高，基本可断定是 netpoller 瓶颈，而非业务逻辑问题
netpoller 本身不暴露接口供用户直接调用，它的存在感只在你试图“横向扩展单进程网络吞吐”时突然变得非常强硬 —— 它不配合，也不妥协。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
