不能直接替换 netpoller 为自定义 epoll 循环，因为 netpoller 与 goroutine 调度深度绑定：conn.Read() 触发 gopark 挂起 goroutine，epoll 就绪后 runtime 自动 goready；手动调用 epoll 会绕过调度闭环，导致 goroutine 泄漏、GC 不安全、select 卡死及连接状态丢失。
为什么不能直接替换 netpoller 为自定义 epoll 循环
go 的 net 包不是“用了 epoll”，而是把 epoll 和 goroutine 调度器绑死了——conn.read() 看似阻塞，实则触发 gopark 挂起当前 goroutine，并由 runtime 在 epoll 就绪后自动 goready。你一旦绕过 net.conn、手动调 unix.epollwait，就等于主动退出 go 运行时的调度闭环。
常见后果包括：
-
goroutine泄漏：手动管理 fd 生命周期时，忘记unix.Close(fd)或未从 epoll 实例中EPOLL_CTL_DEL，导致 fd 耗尽（EMFILE） -
GC不安全：裸 fd 不受 Go runtime 管理，runtime.SetFinalizer无法绑定清理逻辑 -
select卡死：自定义 epoll 循环中若混用chan和unix.EpollWait，可能因 goroutine 唤醒路径断裂导致 channel 永久阻塞 - 连接状态丢失：原生
net.Conn自带SetReadDeadline、SetKeepAlive等语义，手动 epoll 需全部重实现
哪些场景真值得动 epoll 层
只有当标准库的抽象成为瓶颈时才考虑下沉。典型信号是 pprof 显示大量 goroutine 停在 net.(*netFD).Read 但实际连接数并不高，且已排除业务逻辑卡死（如锁竞争、DB 查询慢），此时再查 runtime.ReadMemStats：若 Mallocs 高 + PauseNs 波动大，说明高频小包导致 buffer 频繁分配/回收，这时可考虑自定义 epoll + sync.Pool 复用缓冲区。
适用场景包括：
- 代理类中间件（如 Redis Proxy）：需零拷贝转发，避免
io.Copy的两次内存拷贝 - 海量短连接网关（每连接平均存活 accept +
goroutine启动开销占比过高 - 协议解析强定制（如私有二进制协议头含动态长度字段）：需在 epoll 回调中做预读判断，而非等
Read返回再解析
如何安全接入 epoll —— 以字节 netpoll 库为参照
字节跳动的 netpoll 库没抛弃 Go 调度模型，而是把 epoll 封装成可插拔的 EventLoop，关键设计点是：
- 每个
EventLoop绑定固定数量 OS 线程（M），避免 runtime 调度器与 epoll 事件循环争抢 M - fd 注册仍走
netFD流程，但PollDesc的唤醒逻辑被重定向到自定义事件队列，而非 runtime 的全局 ready 队列 - 所有 I/O 回调（
OnRead/OnWrite）运行在EventLoop所属 goroutine 内，不触发跨 M 切换 - 连接关闭时，通过
runtime.KeepAlive确保 fd 在回调执行完前不被 GC 回收
如果你自己封装，至少保留 netFD 初始化流程，只替换 pollDesc.waitRead 的底层实现，而不是从 socket() 重新造轮子。
epoll 参数设置的实际影响
直接调 unix.EpollCreate1(0) 只是起点。真正影响性能的是事件模式和等待行为：
-
EPOLLET（边缘触发）必须搭配非阻塞 socket，否则EpollWait可能漏事件；但 Go 原生net.Listen创建的 socket 默认就是非阻塞，这点不用额外设 -
EPOLLONESHOT可防止同一事件被多次触发，适合需要严格顺序处理的场景（如 WebSocket ping/pong），但每次处理完必须显式EPOLL_CTL_MOD重新注册 -
EpollWait的msec参数设为-1表示永久阻塞，设为0则变成轮询（高 CPU），生产环境建议设为1000（1 秒超时），便于嵌入定时任务逻辑 - 事件数组长度（
events := make([]unix.EpollEvent, 128)）不宜过大：超过 512 容易触发内核页分配，也不宜过小：太小会导致单次EpollWait返回后还需多次调用才能清空就绪队列
最易被忽略的一点：epoll 实例本身也是 fd，它没有自动继承 FD_CLOEXEC 标志。若程序 exec 子进程，必须用 unix.FcntlInt(uintptr(epfd), unix.F_SETFD, unix.FD_CLOEXEC) 显式设置，否则子进程会意外持有父进程的 epoll 实例，造成资源泄漏。
