go程序在linux下无需也不能手动优化epoll，所有fd操作均由runtime.netpoll自动托管；所谓“优化”多是误判，真正瓶颈在于上层逻辑干扰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 停摆
SO_REUSEPORT 在单进程 Go 里到底有没有用
SO_REUSEPORT 不是用来提升单进程内并发的——它只对多个独立进程（比如多实例部署）生效，靠内核在多个 listener fd 间分流新连接；在单个 Go 进程里设它，既不加速 accept，也不减少上下文切换。
- 它只作用于 listener fd，对已建立连接的 conn 无影响
- 若你用
GOMAXPROCS=1却开了SO_REUSEPORT，反而可能因进程间竞争加剧accept延迟 - 真正影响
accept效率的是：GOMAXPROCS是否足够、listen backlog 是否太小、handler 是否阻塞 M
高并发下该盯住哪些指标而非 epoll 参数
当你怀疑 epoll 性能瓶颈时，99% 的问题其实出在上层逻辑是否干扰了 netpoll 正常工作：
- 用
curl http://localhost:6060/debug/pprof/goroutine?debug=2查看阻塞在net.(*pollDesc).wait的 goroutine 数量和等待时长；若大量 goroutine 卡在running状态而非 IO wait，说明业务逻辑阻塞了 M -
netstat -s | grep -i "listen"显示ListenOverflows，说明 accept 队列溢出——根本原因是 goroutine 处理accept太慢，或 P 数不足（GOMAXPROCS过低） -
http.Server.ReadTimeout和WriteTimeout必须设；conn.SetReadDeadline()必须每次Read()前重设——deadline 是 per-call 的，不设就等同于无限等待
真正容易被忽略的点是：netpoll 本身不引发 OS 级上下文切换，goroutine 阻塞时仅被 gopark 挂起，M 继续执行其他 G；但一旦你在 handler 里做耗时同步操作（比如大循环、未加 context 的 time.Sleep、无界正则匹配），M 就会被长期占用，导致 netpoll 无法及时轮询其他 fd —— 这才是上下文切换飙升的根源。
