Go语言中netpoller已封装epoll，用户无需也不该手动调用epoll系统调用；conn.Read等操作自动注册fd到epoll并挂起goroutine，数据就绪后唤醒，全程对用户透明。
Go 语言里你无法也不该手动结合 epoll 学习 I/O 多路复用——因为 netpoller 已经把它完全封装掉了，你写的每一行 conn.Read()、http.ListenAndServe() 都在用它，只是你看不见。
为什么你写不出 epoll_create / epoll_wait
Go 运行时（runtime）在 Linux 上确实用 epoll 实现了 netpoll，但它被深度集成进 goroutine 调度系统：当一个 goroutine 在 conn.Read() 上阻塞时，runtime 自动把对应 fd 注册进 epoll 实例，并挂起 goroutine；等内核通知数据就绪，再唤醒它。这个过程对用户代码完全透明。
你不能、也不应该：
- 调用
syscall.EpollCreate1或syscall.EpollCtl—— 会绕过 runtime.netpoll，导致 goroutine 永久阻塞或 panic - 用
os.NewFile包裹裸 fd 后调用Read—— 走的是系统调用阻塞路径，不进 netpoll - 在
http.HandlerFunc里混用 cgo 网络库（如 libcurl）且未设CGO_ENABLED=0—— C 线程阻塞会抢占 P，拖垮整个调度器
想理解 epoll 封装，就从 conn.Read 的行为反推
真正能帮你建立“epoll 感知”的，不是写 epoll 代码，而是观察 Go 网络调用在什么情况下会脱离 netpoll、暴露底层行为差异：
立即学习“go语言免费学习笔记（深入）”；
-
net.Dial不设Context.WithTimeout→ DNS 解析卡在getaddrinfo，走的是阻塞 libc 调用，不经过 epoll -
os.Stdin.Read→ 返回的是 *os.File，其Read是纯阻塞系统调用，会挂起 M，无法并发复用 - 用
net.Listen后手动对 listener fd 调用syscall.SetsockoptInt强设SO_REUSEPORT→ 内核报bind: invalid argument，因为 Go 单进程不支持该语义
这些不是“错误用法”，而是边界案例——它们恰好暴露了 netpoll 的封装边界在哪里。
学习建议：用 strace + netstat 验证封装效果
想确认某段 Go 代码是否真正在用 epoll，别看源码（runtime/netpoll_epoll.go 太深），直接上系统工具：
- 启动服务后执行
strace -p $(pgrep your_program) -e trace=epoll_wait,epoll_ctl—— 如果看到高频epoll_wait返回非零值，说明 netpoll 正常工作 - 同时跑
netstat -tnp | grep :your_port和lsof -p $(pgrep your_program) | grep epoll—— 可见 runtime 创建的 epoll fd（通常 fd 编号较大，如 8、9） - 故意让某个连接空闲 30 秒，观察
epoll_wait是否仍被调用（是，因为 netpoll 持续轮询）；再断开连接，看epoll_ctl(EPOLL_CTL_DEL)是否触发（是，说明自动注销）
复杂点在于：netpoll 不是独立模块，它和 goroutine 的 park/unpark、M 的 sysmon 监控、P 的本地运行队列交织在一起。你看到的“一次 Read”，背后可能是三次 epoll_wait、两次 goroutine 切换、一次定时器检查——但只要你不碰裸 fd、不混用 cgo、不滥用阻塞系统调用，这些细节就真的不需要你操心。
