Go 的 netpoller 不直接调用 epoll/kqueue 是因为 runtime 已将其封装进 goroutine 调度流程，自动管理 fd 注册/注销；手动混用会导致 EBADF、调度失衡等问题，且默认由 runtime 自动适配各平台 IO 多路复用机制。
Go 的 netpoller 为什么不用直接调用 epoll/kqueue
Go 运行时自己封装了一套事件循环，netpoller 是它的核心组件，但你写 Go 网络服务时几乎从不直接碰 epoll_ctl 或 kqueue ——不是不能，而是没必要。Go 的 runtime.netpoll 已经把系统调用封装进 goroutine 调度流程里，所有 net.Conn.Read、net.Conn.Write 都会自动注册/注销 fd 到 poller 中。
常见错误现象：有人试图用 syscall.EpollWait 混合使用标准库 net.Listener，结果 fd 被重复管理，出现 EBADF 或读写阻塞不唤醒；或者在 goroutine 里手动 epoll_ctl 后忘记 runtime.Entersyscall/runtime.Exitsyscall，导致 P 被卡住，调度器失衡。
- Go 的
netpoller在 Linux 上默认用epoll（内核 ≥2.6），macOS 用kqueue，Windows 用IOCP，全部由runtime自动选择，无需配置 - 如果你硬要绕过 netpoller（比如做自定义协议栈或嵌入式裁剪），得用
syscall.RawConn控制底层 fd，但必须配合runtime.SetFinalizer和runtime.Netpoll手动管理生命周期 -
net/http.Server、net.Listen等默认行为已深度绑定 netpoller，强行替换底层事件机制会导致accept失败、连接漏收、超时不触发等问题
什么时候该关心 netpoller 的行为细节
日常写 HTTP 服务或 RPC 接口，你不需要知道 netpoller 怎么工作。但遇到这几类问题时，它就是关键线索：
- 大量短连接下，
pprof显示runtime.netpoll占用高 CPU，说明 epoll/kqueue 事件处理本身没瓶颈，但 goroutine 创建/销毁或回调逻辑太重 - 连接数上万后，
read延迟突增，且/proc/sys/net/core/somaxconn和netstat -s | grep -i "listen"显示有ListenOverflows，说明 accept 队列溢出——这背后是 netpoller 的accept回调没及时被调度，常因 P 数不足或 GC STW 干扰 - 用
SetReadDeadline后超时不生效，大概率是 fd 被重复dup或未关闭，导致 netpoller 仍监听旧 fd，而新 fd 没注册
如何验证当前 netpoller 正在用什么机制
Go 不提供公开 API 查询当前使用的 IO 多路复用后端，但可以通过编译和运行时特征间接确认：
立即学习“go语言免费学习笔记（深入）”；
- Linux 下编译时加
-ldflags="-extldflags '-static'"后运行，若仍能正常处理网络请求，说明用的是epoll（glibc 的 epoll 封装可静态链接）；若失败，可能是 fallback 到select（极罕见，仅发生在非常老的内核或交叉编译缺失头文件时） - macOS 上启动程序时设置
GODEBUG=netdns=cgo并观察日志，虽然不直接暴露 kqueue，但若 DNS 解析走 cgo，说明 runtime 使用了系统原生 syscall，kqueue 就在其中 - 最可靠方式：用
strace -e trace=epoll_wait,kqueue,kevent,ioctl（Linux/macOS 分别）跑一个空http.ListenAndServe，看系统调用输出 —— 你会看到持续的epoll_wait或kevent调用，这就是 netpoller 在轮询
修改 GOMAXPROCS 或启用 GODEBUG=nethttpdidntclose 会影响 netpoller 吗
不会直接影响 netpoller 的实现逻辑，但会显著改变它的工作负载分布：
-
GOMAXPROCS决定 P 的数量，每个 P 绑定一个netpoller实例（Linux 上是独立epoll fd）。P 太少（如GOMAXPROCS=1）会导致所有 goroutine 共享一个 epoll 实例，高并发时事件分发成为瓶颈；太多（如远超 CPU 核心数）则增加上下文切换和 epoll fd 管理开销 -
GODEBUG=nethttpdidntclose=1只影响net/http包内部对连接复用的判断逻辑，不修改 netpoller 行为。但它会让本该复用的连接提前关闭，导致更多accept和close系统调用，间接加重 netpoller 的 fd 注册/注销压力 - 真正影响 netpoller 效率的是
runtime.SetMutexProfileFraction或频繁调用debug.SetGCPercent，它们会干扰调度器与 netpoller 的协同节奏，造成事件延迟抖动
netpoller 的复杂点不在接口，而在它和调度器、内存分配器、GC 的紧耦合——你改一行 net.Conn 的用法，可能牵动三处 runtime 行为。所以别想着“优化 netpoller”，先确保你的连接生命周期清晰、超时设置合理、goroutine 不泄漏。
