Go中不能手动实现epoll循环，必须依赖netpoll机制；“常驻内存”应通过sync.Pool复用缓冲区、设置四项超时参数（Read/Write/IdleTimeout及MaxHeaderBytes）并配合连接生命周期管理来实现。
go 里没有“基于 epoll 原生网络常驻内存开发”这种合理路径。你真正要做的，是让 net/http.server 或自定义 net.listener 长期持有连接、复用内存结构，并靠 netpoll 自动管理事件——而不是绕过它去手写 epoll 循环。
为什么不能手动实现 epoll 循环来“常驻内存”
手动调用 syscall.EpollCreate1、syscall.EpollCtl、syscall.EpollWait 并维护 fd 生命周期，会直接绕过 Go runtime 的 netpoll 调度机制，导致：
-
syscall.EAGAIN频繁返回却未正确处理，引发空转或 panic - goroutine 不被自动挂起，CPU 占用飙到 100%，pprof 显示大量
running状态而非IO wait - 连接关闭时 fd 未从 epoll 实例中移除，造成 fd 泄露
- 无法兼容 macOS（kqueue）和 Windows（IOCP），彻底失去跨平台能力
常驻内存的正确落地方式：复用 conn + sync.Pool + deadline 控制
所谓“常驻内存”，本质是避免高频分配/释放连接上下文（如 buffer、parser、session struct）。这和 epoll 无关，而是靠 Go 运行时配合业务逻辑实现：
- 用
sync.Pool缓存[]byte缓冲区或自定义协议解析器实例，每次conn.Read()前pool.Get()，读完后pool.Put() - 每个连接对应一个长生命周期 goroutine，但必须设
conn.SetReadDeadline()和conn.SetWriteDeadline()，否则空闲连接永远不释放 - 不要在 handler 里 new 大对象；把 session state 提前初始化好，随 conn 传入，复用其字段
- HTTP 场景下，
http.Server的ConnState回调可用于统计活跃连接数，但不能替代超时控制
百万连接下真正决定“常驻”成败的四个超时参数
漏掉任意一项，“常驻”就变成“驻留泄露”：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
ReadTimeout: 15 * time.Second—— 防止恶意客户端只发 header 不发 body -
WriteTimeout: 15 * time.Second—— 防止 handler 渲染模板卡死或下游 RPC 延迟过高 -
IdleTimeout: 60 * time.Second—— 最关键，强制空闲连接断开，避免ESTABLISHED数量线性堆积 MaxHeaderBytes: 64 —— 限制单次请求头大小，否则 100 万连接 × 1MB header = 直接 OOM
netpoll 的“常驻”不是靠你 hold 住 fd，而是靠 runtime 在 fd 就绪时精准唤醒 goroutine；你唯一要盯紧的，是 goroutine 是否真在等 IO（查 pprof）、内存是否被 buffer 或未回收的 parser 持有、超时是否生效——这些比 epoll_wait 返回值重要得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
