go不暴露epoll调用，因其runtime/netpoll在linux上自动封装epoll_create、epoll_ctl和epoll_wait，所有socket设为o_nonblock，conn.read()表面同步实则由调度器挂起goroutine，无需也禁止手动干预。
Linux 下的 epoll 非阻塞 I/O 和 Go 的网络模型根本不在同一抽象层上——前者是内核提供的系统调用接口，后者是 runtime 封装的协程调度机制。它们不直接“交互”，但 Go 的 net 包在 Linux 上默认就基于 epoll + 非阻塞 socket 实现，只是你几乎不需要、也不应该手动调用 epoll_ctl 或处理 EAGAIN。
为什么 Go 程序里看不到 epoll 调用？
Go 的 runtime/netpoll 在 Linux 上自动封装了 epoll_create、epoll_ctl 和 epoll_wait，所有 socket 都被设为 O_NONBLOCK，并由 netpoll 统一等待就绪事件。你写的 conn.Read() 表面同步，实际会被 runtime 拦截：若无数据，当前 goroutine 会挂起（Gwaiting），而不是忙等或阻塞线程。
- 你无法在 Go 源码中显式看到
epoll_wait调用——它藏在runtime.netpoll的汇编/Go 混合实现里 -
net.Listener.Accept()返回的net.Conn已自动配置为非阻塞，无需再调用fcntl(sockfd, F_SETFL, O_NONBLOCK) - Go 不暴露
EPOLLET控制权；它内部使用水平触发（LT）模式，靠 goroutine 调度隐式实现“一次性读完”的语义
手动混用 epoll 和 Go 代码会出什么问题？
如果你在 Go 中用 cgo 调用 epoll_wait，或通过 syscall 直接操作 fd，会绕过 Go runtime 的网络调度器，导致严重问题：
- goroutine 可能永远卡在
epoll_wait上，因为 runtime 不知道这个 fd 被你“抢走”了 - 同一个 fd 被
net.Conn和你手写的 epoll 同时监听，触发重复事件或EBADF - 关闭连接时，Go 的
conn.Close()可能提前释放 fd，而你的 epoll 循环还在等它，出现epoll_ctl: Bad file descriptor
什么时候需要关心底层 epoll 行为？
绝大多数 Go 网络服务完全不用碰 epoll，但以下场景需注意其间接影响：
- 高并发短连接（如 HTTP 爆发请求）：Go 默认复用
epoll实例，但大量accept+ 立即close会导致TIME_WAIT堆积，此时要调SetNoDelay(true)或启用端口复用（SO_REUSEPORT） - UDP 场景：Go 的
net.UDPConn底层也是非阻塞 +epoll，但不支持连接状态管理，ReadFrom失败时返回syscall.EAGAIN，而非 panic——这点和 TCP 不同，容易漏判 - 调试性能瓶颈时：
/proc/[pid]/fd/下查看 fd 数量，strace -e epoll_wait,read,write可确认是否真由 runtime 控制，避免误以为“Go 没用 epoll”
真正需要动手调 epoll 的，通常是 C/C++/Rust 编写的高性能代理或协议栈；Go 的设计哲学就是把这一层彻底收口。别试图“优化”它——除非你清楚自己正在覆盖 runtime 的调度契约。
