Go 使用 netpoll 而非 epoll，其底层在 Linux 基于 epoll 封装，但跨平台抽象为 kqueue/IOCP；手动实现 epoll 循环会绕过 goroutine 调度、引发 EAGAIN、CPU 100%、goroutine 泄漏等问题。
Go 里没有 epoll，netpoll 才是实际机制
Go 的运行时网络调度不暴露 epoll，也不让你手动调用它。你写的 net.Listener.Accept()、conn.Read() 看似阻塞，背后全是 netpoll（Linux 下基于 epoll 封装，但 macOS 是 kqueue，Windows 是 IOCP）。强行“实现 epoll 事件循环”不仅没必要，还会绕过 Go 的 goroutine 调度优势，大概率写出 bug。
常见错误现象：syscall.EAGAIN 或 syscall.EWOULDBLOCK 频繁出现、CPU 100%、goroutine 泄漏——这些往往是因为手动轮询 epoll_wait + 非阻塞 socket，却没处理好就绪状态与 goroutine 生命周期的同步。
- Go 程序员该关心的是：怎么让
netpoll正常工作，而不是替换它 - 所有标准库
net操作（http.Server、net.Listen）默认已启用netpoll - 如果你在写底层网络库（比如自研 TCP 代理），也应复用
runtime.netpoll接口，而非直接 syscall
想控制事件循环？用 net.Conn 的 SetReadDeadline 和 SetWriteDeadline
真正需要“事件驱动感”的场景（比如长连接心跳、协议解析分阶段），靠设置 deadline + 非阻塞读写即可达成类似效果，且完全兼容 goroutine 模型。
使用场景：IM 消息分帧、MQTT 连接保活、自定义二进制协议解析
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
conn.SetReadDeadline(time.Now().Add(5 * time.Second))后调用conn.Read()，超时会返回net.ErrDeadlineExceeded，不是 panic - 不要在循环里反复
SetReadDeadline却不重置时间——容易误判为“永远无数据” - deadline 是 per-call 的，每次
Read/Write前都得设一次；如果想长期有效，需在每次 IO 前重新计算时间点 - 注意：deadline 对
Accept()无效，监听套接字要用net.ListenConfig的KeepAlive参数控制连接存活
调试 netpoll 行为：看 GODEBUG 和 pprof 里的 goroutine stack
当你怀疑事件没触发、连接卡住、goroutine 堆积，不是去翻 epoll_wait 返回值，而是检查 Go 运行时是否真在等待 IO。
性能影响：滥用 runtime.Gosched() 或空 for {} 循环会掩盖 netpoll 等待，让 pprof 显示大量 running 状态，实则 IO 已就绪但逻辑没推进
- 启动时加
GODEBUG=netdns=go+2可看到 DNS 解析是否走 netpoll；GODEBUG=asyncpreemptoff=1可临时禁用抢占，方便观察 IO 阻塞点 -
curl http://localhost:6060/debug/pprof/goroutine?debug=2查看阻塞在net.(*pollDesc).wait的 goroutine，确认它们是否真在等 IO - 避免在 handler 里做耗时同步计算（如 JSON 解析、加密）——这会让 netpoll 线程被占住，影响其他连接响应
非标准需求：必须对接 epoll？用 syscall.RawConn 但慎入
极少数情况（比如和 C 库共用 fd、实现零拷贝收发），才需要绕过 netpoll 直接操作 fd。这时必须用 syscall.RawConn，且要自己管理就绪通知与 goroutine 唤醒。
容易踩的坑：fd 被 runtime 关闭、epoll_ctl 误删事件、goroutine 永远收不到唤醒信号
- 获取 raw conn：
raw, _ := conn.(syscall.Conn).SyscallConn()，之后所有 IO 必须用raw.Read/raw.Write - 注册事件前，先调用
raw.Control获取 fd，并确保该 fd 没被 runtime 标记为 closed - 唤醒 goroutine 不能只靠 channel send，必须配合
runtime.Entersyscall/runtime.Exitsyscall，否则调度器无法感知阻塞态 - 一旦用了
RawConn，该连接就脱离 netpoll 管理——超时、关闭、错误传播全得自己实现
复杂点在于：netpoll 不是黑盒，但它的状态机和 runtime 调度深度耦合。你以为在控制 epoll，其实是在和 GC、抢占、栈增长打配合战。多数人掉进去，最后还是换回标准 net.Conn。
