Go语言标准库网络I/O已默认基于epoll/kqueue/IOCP实现多路复用，用户不应手动调用epoll等系统调用，因其会绕过runtime.netpoll调度，导致goroutine永久阻塞或抢占OS线程；select语句是唯一可控的多路复用入口，仅操作channel、不涉及fd，由编译器转为原子检测，配合default可实现非阻塞轮询，但高频使用易致CPU空转。
go 语言本身不提供“手动实现多路复用”的接口，标准库所有网络 i/o（net.conn、http.server、net.listener）已默认基于 epoll/kqueue/iocp 实现多路复用——你写的 conn.read() 看似同步，实则由 runtime.netpoll 在背后调度，无需也**不应**自己封装 epoll_ctl 或轮询 epoll_wait。
为什么不能也不该手动调用 epoll
直接使用 syscall.EpollCreate1 + syscall.EpollCtl 会绕过 Go 的调度器：
-
netpoll不知道你注册的 fd，不会在事件就绪时唤醒对应 goroutine，导致 goroutine 永久阻塞或 panic - 裸 fd 上的
Read/Write走系统调用阻塞路径，挂起 M（OS 线程），抢占 P，拖垮整个程序并发能力 - 手动管理 fd 生命周期极易出错：忘记
close()、重复epoll_ctl(DEL)、未处理EPOLLHUP等都会引发资源泄漏或崩溃 -
SO_REUSEPORT对单进程 Go 程序无效——它依赖内核对多个独立进程的负载分发，而 Go 默认只启一个进程
select 语句是用户层唯一可控的多路复用入口
select 不操作文件描述符，只协调 channel 通信，但它正是 Go 多路复用逻辑的暴露面：
- 每个
case <-ch或case ch <- x都会被编译器转为对 channel 底层状态的原子检测，无锁、无系统调用 - 若所有
case都不可执行且无default，goroutine 进入休眠并自动注册到相关 channel 的等待队列；事件触发后由 runtime 唤醒 - 含
default的select是非阻塞轮询，但高频执行会导致 CPU 空转，仅适用于超短时兜底逻辑（如快速退出检查） - 空
select{}会永久阻塞并标记 goroutine 为 “waiting on channel”，常用于主 goroutine 等待信号，但误用易致死锁
真正需要关注的“多路复用失效点”
性能断崖往往不出现在网络层，而出现在那些**脱离 netpoll 调度的 I/O 场景**：
-
os.Stdin.Read()、*os.File.Read()：除非显式设为非阻塞并配runtime.Entersyscall，否则阻塞 M，无法并发 - cgo 调用 C 网络库（如 libcurl）且未禁用 CGO：
CGO_ENABLED=0缺失时，C 线程阻塞会卡住 P -
net.Dial未设Context超时：DNS 解析可能卡在getaddrinfo，走 libc 阻塞路径 -
time.Sleep或密集计算在http.HandlerFunc中：不触发 I/O，但占着 goroutine，降低吞吐
这些地方才是实际开发中容易被忽略、却真实拖垮并发表现的关键点——它们让本该并行的逻辑退化成串行等待。
