Go程序中所有网络操作均不手动调用epoll_ctl，而是由runtime.netpoll自动完成EPOLL_CTL_ADD/DEL；每个net.Conn对应netFD和pollDesc，后者是epoll注册状态的唯一权威来源；手动调用epoll_ctl会导致EBADF、goroutine挂起等严重问题。
Go 程序里根本不会调用 epoll_ctl
你写的 net.listen、conn.read 或 http.serve 全部不涉及手动 epoll_ctl 调用。go 运行时在初始化网络 fd 时，已由 runtime.netpoll 自动完成 epoll_ctl(epoll_ctl_add)；连接关闭时，也由运行时在 close 路径中触发 epoll_ctl_del。你无法、也不该在用户代码里对同一个 fd 再调一次 epoll_ctl——这会导致内核返回 ebadf，或让该 fd 在就绪队列里反复触发、读写永久挂起。
epoll_ctl 的注册时机完全由 netFD 和 pollDesc 控制
每个 net.Conn 底层对应一个 netFD，它持有一个 pollDesc。这个结构体不是装饰品，而是 epoll 注册状态的唯一权威来源：
-
pollDesc.fd是真正传给epoll_ctl的文件描述符值 -
pollDesc.rg/wg存着等待读/写的 goroutine 指针，epoll 就绪后 runtime 就靠它唤醒对应 G -
pollDesc.seq和pollDesc.closing防止在 fd 关闭后，旧的 epoll 事件还试图唤醒已销毁的pollDesc
换句话说：你调 conn.SetReadDeadline()，本质是更新 pollDesc.rt 和重置 pollDesc.rseq；你调 conn.Close()，runtime 会先发 EPOLL_CTL_DEL，再 close fd —— 全自动，无感知。
手动混用 epoll_ctl 的典型崩坏现场
一旦你在 Go 程序里 import "syscall" 并显式调用 epoll_ctl，哪怕只加了一次，后果就是连锁失控：
- 同一 fd 被运行时和你的代码分别注册进不同 epoll 实例（或同一实例但重复 add），内核判定 fd 状态混乱，后续
epoll_wait返回EBADF - 你没配
runtime.Entersyscall/runtime.Exitsyscall，M 线程卡死在系统调用里，P 无法调度其他 goroutine，整个程序吞吐归零 -
conn.SetReadDeadline()失效：因为超时依赖pollDesc上的定时器与 runtime.netpoll 协同，手动 epoll 绕过了这套机制 - pprof 查看 goroutine 堆栈时，大量 G 停在
runtime.netpoll或internal/poll.runtime_pollWait，但实际已无法响应新事件
真要观察 epoll_ctl 行为，得看内核视角
想确认某个 fd 是否被正确注册进 epoll，别翻 Go 源码，直接查进程级内核状态：
- 查 epoll 实例：
ls -l /proc/<pid>/fd/ | grep epoll，能看到类似epoll:[12345]的条目 - 查注册的 fd 数量：
cat /proc/<pid>/fdinfo/<epoll_fd>，里面events:行会列出当前监听的 fd 列表（需 kernel ≥ 4.18） - 抓系统调用：
strace -p <pid> -e trace=epoll_ctl,epoll_wait 2>&1 | grep EPOLL_CTL_ADD，能看见 runtime 实际注册动作（注意：仅限调试，线上禁用）
这些输出里的 fd 编号，必须和你代码中 netFD.pfd.Sysfd 的值一致，才说明 netpoll 正常接管了该连接。任何不一致，都意味着你或第三方库偷偷绕过了 net 包。
