netpoller不是供开发者直接调用的api，而是go运行时自动初始化并绑定到m0线程的内部组件，所有标准库网络操作均透明使用它，无法显式启动、配置或替换。
netpoller 不是供 Go 开发者直接调用的 API，它属于运行时内部组件，标准库中没有公开的函数、类型或文档让你“使用”它——你写 http.ListenAndServe 或 net.Listen 时，它就在后台自动工作了。
别试图“调用 netpoller”，它根本不是 API 层面的东西
你翻遍 go doc net、go doc runtime，都找不到 netpoller 这个标识符。它被定义在 runtime/netpoll.go（Linux 下是 netpoll_epoll.go），由 Go 启动时自动初始化，且只绑定到 M0 线程。所有网络 I/O 操作（conn.Read、conn.Write、listener.Accept）底层都会触发它，但你无法显式启动、配置或替换它。
- 常见错误：搜索 “how to use netpoller in Go” 后尝试 import
"runtime/netpoll"—— 包不存在，编译失败 - 另一个坑：以为
net.Conn.SetDeadline是在操作 netpoller —— 实际上只是设置内核 socket 的超时，netpoller 仍按原逻辑等待事件 - 真正暴露给用户的“轮询接口”只有
select+ channel 组合，比如监听ctx.Done()、time.After()、自定义事件 channel
想理解 netpoller，必须从网络 I/O 行为反推
观察一个 http.HandlerFunc 的实际执行路径，比读源码更直观：
- 当客户端发起请求，
http.Server调用listener.Accept()→ 底层触发epoll_wait等待就绪连接 - Accept 返回后，新
net.Conn的读操作（如bufio.Reader.Read）若无数据，goroutine 就挂起，pollDesc.rg字段被设为当前 goroutine 指针 - 数据到达时，netpoller 唤醒该 goroutine，调度器将其置为 runnable，继续执行 handler
- 整个过程对用户透明：你没写任何轮询逻辑，但并发数轻松上千 —— 这就是 netpoller 在替你干活
验证 netpoller 是否生效，看三个现象
不用调试器，靠行为判断它是否正常工作：
- 高并发下 CPU 占用集中在单个核心（
top -H查看 M0 线程）：说明 epoll_wait 在跑，不是多线程轮询 - 1000 个空闲连接长期保持，内存增长平缓（
runtime.ReadMemStats观察MCacheInuse）：说明 goroutine 处于 _Gwaiting，未泄漏 - 连接断开后，对应 handler goroutine 几乎立刻退出（加
log.Printf("done")在 handler 末尾）：说明req.Context().Done()被 netpoller 正确传播
绕过 netpoller 瓶颈的唯一正解是 SO_REUSEPORT
如果你压测发现单机 QPS 卡在 3–5 万上不去，且 epoll_wait 调用耗时飙升，问题不在代码，而在 netpoller 本身是单线程的。此时：
- 不要尝试 “起多个 http.Server 监听同一端口” —— 必然报
address already in use - 必须用
net.ListenConfig{Control: setReusePort}显式开启SO_REUSEPORT，并配合多进程部署（如 systemd 启动 4 个实例） - 每个进程独立拥有自己的 epoll 实例和 M0 线程，这才是真正的横向扩展
- Nginx 的 upstream 配置或 DNS 轮询无法解决这个瓶颈，它们只分发已建立的连接，不参与 accept 阶段的内核分流
netpoller 的复杂性藏在它的不可见性里：你看不见它，就容易误以为自己能控制它；你一试图绕过它，又会撞上内核机制的硬边界。真正掌握它，不是学会怎么调用，而是清楚它何时介入、何时退出、以及当它成为瓶颈时，系统级的解法是什么。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
