go netpoll 不是可直接调用的长连接库，而是底层i/o多路复用机制；可靠长连接需结合net.conn、显式心跳、read/writedeadline动态设置及goroutine协同关闭来实现。
Go 原生 netpoll 本身不提供“长连接库”——它只是运行时底层 I/O 多路复用机制，所有 net.Conn 操作（包括 conn.Read、conn.Write）都自动走它，你无法直接 import 或调用 netpoll。 所谓“基于 netpoll 开发的轻量级长连接库”，实际是指：利用 Go 标准库 net + 显式心跳保活 + 连接生命周期控制，构建出能稳定维持数分钟至数小时的 TCP 连接。这不是框架封装出来的功能，而是业务逻辑层必须补足的关键环节。
为什么 conn.Read() 会突然返回 io.EOF 而不是超时？
这是最典型的表现：服务端或客户端某次 conn.Read() 阻塞几十秒后直接返回 io.EOF 或 read: connection reset by peer，但双方都没调 conn.Close()。
- 根本原因不是 Go 的 bug，而是中间网络设备（NAT 网关、云 SLB、防火墙）在连接空闲 5–30 分钟后静默回收了 TCP 连接
-
net.Conn层面无法感知链路断开，直到下一次读写触发内核返回错误 -
SetReadDeadline()不是“保活开关”，它只对下一次Read()生效；不重置就失效，之后的读操作将阻塞或立即报错 - 不要在 goroutine 启动前统一设置一次 deadline——并发读写会互相覆盖，必须每次成功读完数据后立刻重置
如何用 SetReadDeadline + 心跳实现可靠长连接？
核心逻辑是“读驱动保活”：只要还能读到数据（哪怕只是 "ping"），就说明链路还通；一旦读超时，立刻关闭连接并通知上层重连。
- 服务端示例中，每次
conn.Read()成功后，必须紧跟conn.SetReadDeadline(time.Now().Add(30 * time.Second)) - 客户端发送
"ping"后，要立刻调conn.SetReadDeadline()等待"pong"，超时即判定失联 - 心跳协议建议用固定长度 header + body，避免粘包干扰判断；不要依赖
time.Ticker定时发 ping——对方收不到你也不知道 - 务必区分读超时和写超时：
SetWriteDeadline()要单独设置，尤其在大包推送场景下，否则可能卡住整个连接
goroutine 泄漏比连接泄漏更危险
常见错误是为每个连接起两个 goroutine：go readLoop(conn) 和 go writeLoop(conn)，但没做退出同步。
- 当
readLoop因超时退出并调conn.Close()后，writeLoop若仍在往已关闭的conn.Write()写，会 panic 或永久阻塞 - 推荐用
sync.Once+chan struct{}控制关闭信号，确保读写 goroutine 共享同一个 done channel - 不要用
select { case 做心跳定时器——它不感知连接状态，容易在连接已断时还空转 - 用
kill -SIGQUIT <pid></pid>查看 goroutine 堆栈，若大量停在internal/poll.runtime_pollWait或conn.Write，基本就是泄漏了
真正难的不是写一个能连上的 demo，而是在高并发下让百万连接都“活着且可控”：每个连接的 deadline 设置时机、心跳响应路径是否可测、close 信号能否原子广播、错误是否被吞掉——这些细节不压测根本暴露不出来。
