go程序不应手动使用epoll系统调用，因标准库net已通过runtime.netpoll自动封装调度；手动介入会破坏goroutine与事件循环耦合，导致阻塞、panic或资源泄漏。
Go 程序不需要、也不应该基于原生 epoll 系统调用重构网络引擎——标准库的 net 已通过 runtime.netpoll 完全封装并自动调度，手动介入只会破坏 goroutine 与事件循环的耦合机制，引发阻塞、panic 或资源泄漏。
为什么 epoll_ctl + epoll_wait 在 Go 里是危险操作
你写的 conn.Read() 看似同步，实则由 Go runtime 自动挂起 goroutine 并注册 fd 到 netpoll；而直接用 syscall.EpollCreate1 创建 epoll 实例、再用 syscall.EpollCtl 手动管理 fd，会绕过整个 netpoll 调度链路：
- goroutine 不再能被
gopark/goready正确唤醒，可能永久处于IO wait状态却无法响应事件 -
net.Conn底层的PollDesc与你的 epoll 实例无关联，超时、关闭、错误通知全部失效 - 若对裸
os.File.Fd()调用read()系统调用（而非conn.Read()），会触发runtime.Entersyscall，挂起 M，导致其他 goroutine 饥饿 - 多个 goroutine 同时对同一 epoll fd 调用
EpollWait，需自行处理并发竞争和事件分发，极易漏事件或重复处理
哪些场景真会绕过 netpoll？
不是所有“用了 fd”的代码都安全。以下操作会让 I/O 脱离 Go 调度器控制，实际效果等同于手动 epoll 却没配套调度逻辑：
-
os.Stdin.Read()或任意*os.File上未设非阻塞模式的读写（如日志文件轮转中用os.OpenFile后直接Read） - 用
cgo调用 C 网络库（如libcurl、openssl的 BIO）且未配置CGO_ENABLED=0，C 函数阻塞时会抢占 P - 在
http.HandlerFunc中调用time.Sleep或密集计算，虽不涉及 I/O，但会占用 goroutine，拖慢整体吞吐 - DNS 解析卡住：
net.Dial默认用系统getaddrinfo，可能阻塞在 C 库，应改用net.Resolver+WithContext
SO_REUSEPORT 对 Go 单进程毫无意义
有人看到 “Linux 多进程共享端口提升吞吐”，就尝试给 net.Listen 加 SO_REUSEPORT，结果报错 bind: invalid argument 或性能下降：
-
SO_REUSEPORT是内核对**多个独立进程/线程**的负载分发机制，Go 单进程只启一个os.Process，该 flag 完全无效 - Go 天然靠
goroutine + netpoll实现单线程轮询万级连接，无需内核分发 - 强行用
syscall.SetsockoptInt设置该 flag，会因 fd 类型不匹配直接失败，且破坏netFD初始化流程 - 真要多进程部署，应由外部进程管理器（如 systemd、supervisord）启动多个 Go 实例，各自监听不同端口或用反向代理分流
真正需要关注的，从来不是“怎么用 epoll”，而是“哪些操作让 netpoll 失效”。只要坚持用 net.Listener、net.Conn、http.Server 等标准接口，并设好 SetReadDeadline/SetWriteDeadline，你就已经运行在 epoll/kqueue/iocp 之上——只是它藏在 runtime 里，安静、可靠、无需你操心。
