Go 的 net.Conn 不直接暴露 epoll，其底层由 runtime.netpoll 自动管理 I/O 多路复用；用户无法也不应手动调用 epoll 相关系统调用，所有标准网络操作已默认受益于该机制。
Go 的 net.Conn 本质不直接暴露 epoll
很多人以为 Go 程序能“手动调用 epoll”来优化网络性能，这是误解。Go 的 net/http、net.Listener 等底层确实基于 epoll（Linux）、kqueue（macOS）或 iocp（Windows），但 runtime 封装得非常深——你无法在用户代码里显式创建 epoll_fd、调用 epoll_ctl 或轮询 epoll_wait。
真正起作用的是 Go 的 runtime.netpoll，它在 goroutine 阻塞于 I/O 时自动注册 fd 到事件驱动引擎，并唤醒对应 goroutine。你写的 conn.Read() 看似同步，实则被调度器接管。
- 不要尝试用
syscall.EpollCreate1+syscall.EpollCtl手动管理连接：会绕过 Go 的 netpoll，导致 goroutine 永久阻塞或 panic - 所有标准库网络操作（
http.ListenAndServe、net.Listen、conn.Write）已默认享受 IO 多路复用红利 - 如果你用
os.File包裹裸 fd 并调用Read，那走的是系统调用阻塞路径，不经过 netpoll
什么时候该关心 epoll 行为？看 netpoll 是否被绕过
真正需要警惕的，是那些“看似网络 I/O、实则脱离 Go 调度”的场景。它们会让本该并发处理的请求变成串行等待，性能断崖下跌。
-
os.Stdin.Read或任意*os.File上的阻塞读：除非显式设为非阻塞并配合runtime.Entersyscall，否则会挂起 M，无法利用多路复用 - 用
cgo调用 C 网络库（如 libcurl）且未设置CGO_ENABLED=0：C 线程可能阻塞，抢占 P，拖慢其他 goroutine - 在
http.HandlerFunc中调用time.Sleep或密集计算：不涉及 I/O，但会占用 goroutine，间接降低并发吞吐 - 使用
net.Dial连接超时未设，DNS 解析卡住：Go 默认用系统解析器，可能阻塞在getaddrinfo，需改用net.Resolver+WithContext
net.Listen 的 SO_REUSEPORT 和 epoll 效果无关
有人听说 “多个进程绑定同一端口可提升吞吐”，就给 net.Listen 加 SO_REUSEPORT，结果发现没变化甚至更慢——因为 Go 默认只启一个 os.Process，而 SO_REUSEPORT 是内核对多个独立进程/线程的负载分发机制，不是给单个 Go 程序内部用的。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- Go 单进程天然靠 goroutine + netpoll 实现高并发，不需要也用不上
SO_REUSEPORT - 若真要多进程（比如用 systemd 启多个实例），需自行 fork 或用外部进程管理器，Go 标准库不提供
SO_REUSEPORT绑定接口 - 误用
syscall.SetsockoptInt强设该 flag 可能导致bind: invalid argument
想验证是否真在用 epoll？看 strace 输出里的 epoll_wait
最直接的办法不是读源码，而是运行时观察系统调用。启动服务后用 strace -p $PID -e trace=epoll_wait,epoll_ctl,read,write，你会看到：
epoll_wait(3, [], 128, 0) = 0
epoll_wait(3, [{EPOLLIN, {u32=14, u64=14}}], 128, -1) = 1
read(14, "GET / HTTP/1.1\r\n...", 4096) = 123
这说明 runtime 正在用 epoll 等待事件，收到后才触发 read。如果只看到大量阻塞 read 调用且无 epoll_wait，大概率是代码绕过了 netpoll。
- 确保程序用
net/http.Server.Serve或net.Listener.Accept启动，而非自己写for { conn, _ := listener.Accept(); handle(conn) }且没做任何并发控制 - 避免在
Accept循环里直接conn.Read而不启 goroutine：会串行处理每个连接，失去多路复用意义 -
strace本身有开销，仅用于诊断，别长期开着
epoll 是隐式生效的基础设施，不是你要调用的 API。真正要盯紧的，是哪些操作会把它“关掉”。
