不应基于原生epoll重构Go底层网络包，因其会绕过runtime调度机制，导致goroutine挂起、M阻塞、fd泄漏；正确做法是复用netpoll，仅在reactor层优化。
不要基于原生 epoll 系统调用重构 Go 底层网络包。这不是优化，而是主动绕过 Go runtime 的调度保障机制，大概率导致 goroutine 永久挂起、M 阻塞、连接泄漏，甚至 panic。
为什么 syscall.EpollWait 会让 goroutine 卡死在 running 状态
Go 的 net 包不是“没用 epoll”，而是把 epoll 和 gopark/goready 绑死了——每个 conn.Read() 背后都关联着一个 PollDesc，它记录了该 fd 上等待的 goroutine 地址。一旦你跳过 netFD 流程，自己用 os.NewFile 拿 fd、再调 syscall.EpollCtl 注册，runtime 就完全丢失对该 fd 的状态跟踪：
-
Read()不再触发gopark，而是走裸系统调用阻塞路径，直接卡住整个 M -
epoll_wait返回后，没有对应PollDesc可查，无法唤醒任何 goroutine - 连接异常断开（如 RST）、超时、关闭等事件，都不会触发清理逻辑，fd 无法被回收
- pprof 查看 goroutine 状态会显示
running或syscall，而非正常的IO wait
哪些场景看似需要手动 epoll，实则只需改用标准库正确姿势
性能瓶颈或控制力不足，90% 出现在上层使用方式，而非底层缺失：
-
http.Server吞吐低？检查是否开了TCP_NODELAY、ReadDeadline是否设置、handler 是否含未带context的time.Sleep - 连接数多导致 GC 压力大？用
sync.Pool复用bufio.Reader/bufio.Writer，别自己管理 fd 生命周期 - 想更快感知断连？启用
SetKeepAlive+SetKeepAlivePeriod，不是重写 epoll 循环 - 需要自定义编解码或连接复用？直接用
gnet或KiteX，它们已基于netpoll把 reactor 分片、buffer 复用、goroutine 池做完了
真有不可绕过的需求，该从哪安全切入
极少数情况（如硬件卸载、零拷贝收发）确实需要贴近 epoll，但必须守住 runtime 边界：
- 实现
net.Listener接口，但内部仍走netFD初始化流程，不绕过runtime.netpoll - 若必须调
epoll_wait，需严格包裹在runtime.Entersyscall/runtime.Exitsyscall内，并确保 fd 由netFD创建并持有 - 参考
gnet或字节netpoll：它们没重写 epoll，而是复用 Go runtime 的netpoll事件循环，只在 reactor 层做分片与 worker 隔离
最易被忽略的一点：net.Listen() 创建的监听 socket 和后续 accept() 得到的连接 socket，都会被自动注册进同一个 epoll 实例——这是 runtime 自动完成的，你手动再注册一次，反而会破坏 fd 状态同步。别碰 syscall.Epoll*，除非你已读完 runtime/netpoll.go 全文并理解每个原子字段的语义。
