不应手动调用 epoll 系统调用，因 go 的 net 包已深度集成 runtime.netpoll 实现稳定高效的 i/o 多路复用；手动调用 syscall.epoll* 会绕过调度器，导致 goroutine 永久挂起、m 阻塞、连接泄漏甚至 panic。
不要基于原生 epoll 系统调用重构 Go 底层网络驱动框架。 Go 的 net 包不是“没用 epoll”，而是已经用得极深、极稳——你手动调 syscall.EpollCreate1、syscall.EpollCtl、syscall.EpollWait，只会绕过 runtime.netpoll，导致 goroutine 永久挂起、M 被阻塞、连接无法被正确回收，甚至 panic。
为什么手动 epoll 会卡死 goroutine
Go 的调度器依赖 netpoll 对 fd 的状态跟踪和 goroutine 生命周期管理。一旦你用 os.NewFile 或裸 syscall 拿到 fd 并自行注册进 epoll，runtime 就完全失去对该 fd 的感知：
- 调用
fd.Read()时不会触发gopark，而是走系统调用阻塞路径，直接挂住整个 M（OS 线程） -
epoll_wait返回后，没有对应PollDesc绑定，无法唤醒任何 goroutine - 连接异常断开（如 FIN/RST 未读完）、超时、关闭等事件，都不会触发回调或清理逻辑
- pprof 查看 goroutine 状态会显示
running或syscall，而非预期的IO wait
哪些场景看似需要 epoll，实则不该碰 syscall
常见误判点集中在“性能不够”或“控制力不足”，但问题往往出在上层使用方式，而非底层缺失：
-
http.Server吞吐低？先检查是否开了TCP_NODELAY、Read/WriteDeadline是否设置、handler 是否做了同步阻塞操作（如未带 context 的time.Sleep） - 连接数多导致 GC 压力大？用
sync.Pool复用bufio.Reader/Writer，而不是自己管理 fd 生命周期 - 想感知连接断开更及时？启用
SetKeepAlive+SetKeepAlivePeriod，而非重写 epoll 循环 - 需要连接复用或自定义编解码？用
gRPC、KiteX或gnet这类基于 netpoll 的成熟框架，它们已把 reactor 分离、buffer 复用、goroutine 池等做完了
真要深度定制，该从哪入手
如果你确实遇到标准库无法满足的边界需求（比如硬件加速、特殊协议栈、零拷贝收发），可行路径是：
- 用
net.Listener接口实现自定义 listener，但内部仍走netFD流程，不绕过netpoll - 基于
golang.org/x/sys/unix在runtime.Entersyscall/runtime.Exitsyscall边界内安全调用 epoll（极少数嵌入式或内核模块场景） - 参考
netpoll（字节开源）或gnet的设计：它们没重写 epoll，而是复用 Go runtime 的netpoll事件循环，仅在 reactor 层做分片、负载均衡、worker 隔离 - 避免直接操作
syscall.Epoll*；若必须，确保每个 fd 都配对调用runtime.SetFinalizer做 close 清理，否则 fd 泄漏不可避免
最常被忽略的一点：netpoll 不是“可选优化”，它是 Go 网络模型的基石。绕过它，等于放弃 goroutine 调度、放弃并发安全、放弃自动超时和错误传播——所有你以为在“提升控制力”的地方，其实都在亲手拆掉 runtime 的安全网。
