必须引入应用层心跳包——setkeepalive(true)单独使用无效，因linux默认2小时首探，远超nat/slb/路由器30–300秒静默回收阈值，且其探测包易被丢弃，write成功不保证对端可达，无法感知应用层崩溃。
SetKeepAlive(true) 本身不能保活长连接，必须搭配应用层心跳；只靠内核探测在 NAT、云 SLB、家用路由器环境下基本失效。
为什么 SetKeepAlive 单独用没用
Linux 默认首次探测要等 2 小时空闲，而阿里云 SLB、家用光猫普遍 30–300 秒就静默回收连接。即使你调了 SetKeepAlivePeriod(30 * time.Second)，中间设备也大概率丢弃 TCP 层的 KEEPALIVE 探测包——它不带业务语义，防火墙和代理常直接过滤。
-
Write成功返回 ≠ 连接可用：数据可能只进了本机发送缓冲区，对端早已断开 - 服务端
Read突然卡住或返回io.EOF，但客户端毫无感知 - Wireshark 抓不到任何 KEEPALIVE 包，说明系统级配置没生效或被中间链路拦截
必须配应用层心跳：用 time.Ticker 发固定二进制包
每 25 秒发一次轻量心跳（略小于常见 NAT 超时阈值），内容必须是定长、无符号、无换行的原始字节，比如 []byte{0x01}。避免 JSON、字符串时间戳、空格冒号等，否则易被代理识别为非法协议而断连。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 别用
time.AfterFunc：上一次写阻塞会导致下一次延迟，心跳节奏漂移 - 必须在每次
Write前设conn.SetWriteDeadline(time.Now().Add(5 * time.Second))，超时立即关连接 - 写失败时检查错误类型：
io.EOF、net.ErrClosed、os.SyscallError（含ETIMEDOUT/ECONNRESET）都该立刻conn.Close()
SetReadDeadline 必须每次 Read 后重置
很多人设一次就不管了，结果心跳包刚到，deadline 已过期，下一次 Read 直接报 i/o timeout——这不是网络问题，是逻辑漏设。
- 无论读到的是业务数据还是心跳包，只要
n, err := conn.Read(buf)中err == nil，就必须立刻调conn.SetReadDeadline(time.Now().Add(30 * time.Second)) - 连续两次
Read返回net.Error.Timeout()才判定断连，单次抖动不杀连接 - 服务端若不响应 PONG，可省掉应答逻辑，但必须更新
ReadDeadline，否则心跳包一来就触发超时
Go 版本与平台兼容性陷阱
SetKeepAlivePeriod 在 Go 1.19+ 才原生支持；旧版本必须用 syscall 或 golang.org/x/sys/unix 手动设置 TCP_KEEPIDLE/TCP_KEEPINTVL。Windows 上该方法调用成功也不生效，探测周期由系统策略决定。
- 服务端用
net.ListenConfig{Control: func(fd uintptr) { ... }}在 socket 创建时设参数，比 Accept 后再设更可靠 - 客户端连接后需立即做类型断言：
tcpConn, ok := conn.(*net.TCPConn)，再调SetKeepAlive系列方法 - 容器或云环境（如 AWS ALB、阿里云 SLB）默认 4 分钟无流量断连，Go 层再怎么设 30 秒探测也救不回来
真正难的不是发心跳，而是让每一次 Read 和 Write 都带着精确的 deadline 控制，并且把 deadline 更新逻辑嵌进所有数据通路里——漏一次，整条连接就失去感知能力。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
