Go程序员不应手动干预epoll，因runtime.netpoll自动托管所有网络fd；手动调用epoll_ctl/wait会导致冲突、惊群效应及调度停摆；SO_REUSEPORT仅对多进程有效；关键优化在于超时设置与连接复用。
Go 程序员不需要、也不应该手动干预 epoll —— 所有网络 fd 的注册、等待、唤醒均由 runtime.netpoll 自动托管；所谓“上下文切换优化”，本质是避免 Goroutine 阻塞 M，防止 netpoll 调度停滞，而非调优 epoll 本身参数。
为什么不能自己调用 epoll_ctl 或 epoll_wait
Go 的 net.Conn.Read() 看似同步，实则由 runtime 封装为非阻塞 syscall + 自动 park/unpark。一旦绕过标准库直接操作 epoll：
- 手动用
syscall.EpollCreate1创建的 epoll fd 会与 runtime 管理的 netpoll 实例冲突，导致重复注册，read可能永久挂起或返回EBADF - 多个 goroutine 同时对同一 epoll fd 调用
epoll_wait，触发内核惊群效应：CPU 100%、accept延迟飙升、连接建立变慢 - 忘记配对
runtime.Entersyscall/runtime.Exitsyscall，M 被卡住，P 无法调度其他 goroutine，整个 netpoll 停摆
net.ListenConfig.Control 里设 SO_REUSEPORT 有用吗
有用，但仅限特定场景：
- 它只作用于 listener fd，让多个**独立进程**（比如多个 Go 二进制实例）共享同一端口，由内核做连接分流
- 对单个 Go 进程内的 goroutine 无效——Go 的并发靠的是 runtime 调度，不是靠内核分发连接到多个线程
- 若你用
GOMAXPROCS=1却开了SO_REUSEPORT，反而可能因进程间竞争加剧 accept 延迟
真正影响上下文切换开销的三个配置点
高并发下 Goroutine 频繁阻塞/唤醒，本质是 M 被业务逻辑长期占用，导致 netpoll 无法及时轮询其他 fd。关键在控制以下行为：
-
http.Server.ReadTimeout和WriteTimeout：防止空闲连接长期占用 goroutine 和 fd，避免 goroutine 在net.(*pollDesc).wait上堆积 -
conn.SetReadDeadline()必须每次Read()前重设：deadline 是 per-call 的，不设就等同于无限等待，goroutine 会一直 parked，M 被锁死 -
http.Transport.MaxIdleConns和MaxIdleConnsPerHost：减少连接反复建立/关闭带来的 fd 频繁增删，降低 netpoll 内部红黑树操作开销
怎么确认问题真出在 netpoll 调度，而不是 epoll 性能
别盯着 /proc/sys/net/core/somaxconn 或 epoll_wait 耗时——先看运行时指标：
- 用
curl http://localhost:6060/debug/pprof/goroutine?debug=2查看是否大量 goroutine 卡在net.(*pollDesc).wait；若多数处于running状态而非IO wait，说明业务逻辑阻塞了 M -
netstat -s | grep -i "listen"显示ListenOverflows> 0：根本原因是 accept 处理太慢，或GOMAXPROCS过低，P 不够用，不是 epoll 本身慢 - 启动时加
GODEBUG=netdns=go+2，排除 DNS 解析阻塞——它会同步阻塞 M，且不走 netpoll
最易被忽略的是：超时必须显式设、必须每次设；netpoll 不会帮你记住上次设置的 deadline，也不会自动续期。漏掉这一行，就等于把 goroutine 永久交给内核托管，而 runtime 已经失去控制权。
