go原生netpoll不可直接用于开发微型长连接框架，因其是runtime内部调度机制，未导出api、无稳定接口、随版本变更易失效；实际可用的是cloudwego/netpoll等第三方nio库。
直接用 go 原生 netpoll（即 runtime/netpoll）开发“微型长连接框架”不可行——它不是暴露给开发者直接调用的 api，而是 go 运行时内部调度器（go scheduler）用来驱动 net.conn 非阻塞 i/o 的底层机制。
为什么不能直接 import “runtime/netpoll”
Go 标准库中没有 import "runtime/netpoll" 这种用法。该模块是 runtime 内部实现，符号未导出、无文档、无稳定接口，且随 Go 版本频繁变更。试图 hack 它会导致：
- 编译失败（如
undefined: netpoll或链接错误） - 运行时 panic（如
netpoll not initialized） - 在 Go 1.20+ 版本中因 poller 重构（如
pollDesc拆分、netpoll.go移入internal）彻底失效
真正可用的“netpoll”其实是 netpoll 框架（非 runtime）
你搜到的“基于 netpoll 的长连接框架”，99% 指的是开源项目 cloudwego/netpoll（字节跳动维护），它是一个独立的、用户态可导入的高性能 NIO 库，和 runtime/netpoll 同名但完全无关。它的核心是封装 epoll/kqueue，提供 EventLoop、Connection、Dialer 等可编程接口。
正确导入方式是：
import "github.com/cloudwego/netpoll"
常见误操作包括：
- 把
netpoll.NewEventLoop当成标准库函数，却没加 go mod 依赖 - 混淆
net.Conn和netpoll.Connection：后者不兼容io.ReadWriter，不能直接传给json.Decoder等标准库工具 - 忽略
Connection的生命周期管理：它不自动关闭，必须显式调用conn.Close()，否则 fd 泄漏
如何用 cloudwego/netpoll 实现可靠长连接
关键不在“连接不关”，而在“连接不断”。必须同时处理三件事：读超时重置、心跳收发、写保护。典型结构如下：
- 服务端：每次
conn.Read()成功后，立刻调用conn.SetReadDeadline(time.Now().Add(30 * time.Second)) - 客户端：发送
"ping"后，立即设conn.SetReadDeadline(time.Now().Add(5 * time.Second))等"pong"，超时即重连 - 所有
conn.Write()前必须设conn.SetWriteDeadline()，捕获os.IsTimeout(err)而非泛判err != nil - 禁用 goroutine-per-connection 模式：用
netpoll.NewEventLoop+OnRequest回调统一处理，避免连接数上涨时 goroutine 爆炸
比“用对库”更易被忽略的点
长连接稳定性不取决于框架多快，而取决于你是否让连接“被中间设备看见”。NAT 网关、云 SLB、运营商防火墙普遍在 5–15 分钟空闲后静默回收 TCP 连接。仅靠 SetReadDeadline 不够——它只防本地阻塞，不防链路中断。必须主动发心跳（如每 30 秒 Write("ping")），且服务端收到后必须回 "pong" 并重置读超时。漏掉任一环，连接就会在某次 Read() 时突然返回 io.EOF 或 read: connection reset by peer，而你毫无感知。
