Go程序在Linux下无需也不能手动优化epoll——所有fd注册、等待、唤醒均由runtime.netpoll自动托管；所谓“epoll优化”多为误判，真正瓶颈在于上层逻辑干扰netpoll正常工作，如未重设deadline、阻塞M线程或滥用SO_REUSEPORT。
Go 程序在 Linux 下根本不需要、也不能手动优化 epoll —— 所有 fd 的注册、等待、唤醒均由 runtime.netpoll 自动托管；所谓“epoll 优化”，99% 是误判，真正瓶颈几乎都出在上层逻辑干扰了 netpoll 正常工作。
为什么不能自己调用 epoll_ctl 或 epoll_wait
你写的 conn.Read() 看似阻塞，实则由 runtime 自动挂起 goroutine，并把 fd 注册进 epoll；一旦绕过这套机制：
- 手动用
syscall.EpollCreate1+syscall.EpollCtl管理 fd，会导致该 fd 被重复注册，运行时可能返回EBADF，或读写永久挂起 - 多个 goroutine 同时对同一 epoll fd 调用
epoll_wait，直接触发惊群效应：CPU 拉满、accept延迟飙升、连接建立缓慢 - 忘记配对
runtime.Entersyscall/runtime.Exitsyscall，会让 M(OS 线程)被卡住，P 无法调度其他 goroutine，整个 netpoll 停摆
net.ListenConfig.Control 和 SO_REUSEPORT 的真实作用
SO_REUSEPORT 不是用来提升单进程内并发的——它只对多个独立进程（比如多实例部署）生效，靠内核在多个 listener fd 间分流新连接；在单个 Go 进程里设它，既不加速 accept，也不减少上下文切换。
真正影响 accept 效率的是：
-
GOMAXPROCS是否足够：若 P 数太少，accept goroutine 长时间得不到调度，netstat -s | grep -i "listen"会显示ListenOverflows - listener 的 backlog 太小（默认 128），高并发建连时队列溢出，连接被内核丢弃
- HTTP handler 中做了耗时同步操作（如大循环、未加 context 的 sleep），阻塞了 M，导致 netpoll 无法及时轮询其他 fd
上下文切换高发的真实原因和监控点
高并发下上下文切换暴涨，从来不是 epoll 本身的问题，而是 goroutine 长时间占用 M 导致的连锁反应：
- 用
curl http://localhost:6060/debug/pprof/goroutine?debug=2查看阻塞在net.(*pollDesc).wait的 goroutine 数量；若大量 goroutine 卡在running状态而非IO wait，说明业务逻辑阻塞了 M -
pprof中若出现大量runtime.mcall/runtime.gopark栈帧，且伴随长时间系统调用（如syscall.Syscall），大概率是用了time.Sleep或未缓冲的 channel 等待 - 避免在 handler 中做 JSON 解析超大 body、正则匹配长文本、无界 for 循环等操作；必须做时，用
runtime.Gosched()主动让出，或扔给 worker goroutine 处理
netpoll 的“隐藏成本”不在 epoll_wait 调用次数，而在 goroutine 生命周期管理是否轻量——每次连接分配一个 goroutine 是合理的，但让它长期 hold 住 M 就破坏了整个调度模型。最易被忽略的一点：所有 SetReadDeadline 都是 per-call 的，不重设就等于无限等待，最终积压成片阻塞的 goroutine。
