go程序中不存在“自己用epoll与netpoll比吞吐量”的选项，因为netpoll就是go在linux下对epoll的封装与调度集成；手动调用syscall.epoll系列函数会引发ebadf、惊群效应、goroutine泄漏及超时失效等问题。
Go 程序里不存在“自己用 epoll 和 netpoll 比吞吐量”这回事——netpoll 就是 Go 在 Linux 下对 epoll 的封装和调度集成，不是两个可互换的选项。
为什么不能拿 epoll 和 netpoll 做吞吐量对比
你写的 http.Server 或 net.Listener.Accept() 底层已经自动把 listener fd 和每个 conn fd 注册进 epoll；conn.Read() 触发的阻塞，实际是 runtime.netpoll 调用 epoll_wait() 等待就绪后唤醒 goroutine。所谓“手动 epoll”是指绕过 Go 运行时，直接调用 syscall.EpollCreate1、syscall.EpollCtl、syscall.EpollWait —— 这会导致：
- fd 被重复注册：运行时和你的代码各自往同一个 epoll 实例加 fd，内核返回
EBADF或读写永久挂起 - 惊群效应：多个 goroutine 同时调
epoll_wait，CPU 100%，accept 延迟飙升 - goroutine 泄漏：忘记配对
runtime.Entersyscall/runtime.Exitsyscall，M 卡死，P 无法调度其他 goroutine - 超时失效：
SetReadDeadline依赖运行时对 fd 的 pollDesc 管理，手动 epoll 后该机制完全旁路
真正影响吞吐量的是上层控制参数，不是 epoll 本身
netpoll 的 epoll 实例由 runtime 全权管理，你无法也无需调整其红黑树或就绪链表行为。影响实际吞吐的，全是 Go 标准库暴露的配置项：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
http.Server.ReadTimeout/WriteTimeout：防止空闲连接长期占着 goroutine 和 fd -
http.Transport.MaxIdleConns/MaxIdleConnsPerHost：控制复用连接数，减少 fd 频繁增删带来的 epoll_ctl 开销 -
net.ListenConfig.Control中设SO_REUSEPORT：仅对 listener fd 生效，让多个独立进程（如多 worker）共享端口，靠内核分流——不是给单进程内 goroutine 用的 -
conn.SetReadDeadline()必须每次Read()前重设：deadline 是 per-call 的，不设等于无限等待，会卡住整个 goroutine
怀疑吞吐瓶颈时该看什么指标
当你观察到 QPS 上不去、延迟升高，别盯着 epoll_wait 耗时——先确认是否干扰了 netpoll 正常工作：
- 用
curl http://localhost:6060/debug/pprof/goroutine?debug=2查看阻塞在net.(*pollDesc).wait的 goroutine 数量；若大量 goroutine 处于running状态而非 IO wait，说明业务逻辑阻塞了 M，不是 epoll 问题 -
netstat -s | grep -i "listen"显示ListenOverflows：说明 accept 队列溢出，根本原因是 goroutine 处理 accept 太慢，或GOMAXPROCS过低 - 启动时加
GODEBUG=netdns=go+2，确认 DNS 解析是否卡在 cgo，拖慢连接建立
netpoll 不是你要调的“组件”，而是 Go 运行时帮你托底的基础设施。吞吐瓶颈几乎永远出在连接生命周期管理、超时设置、DNS、锁竞争或 GC 压力上，而不是 epoll 本身——强行介入只会让问题更隐蔽、更难诊断。
