Go 的 SetKeepAlive 默认不生效，需显式调用 SetKeepAlive(true) 并配合 SetKeepAlivePeriod（或 syscall 手动设置 TCP_KEEPIDLE/KEEPINTVL/KEEPCNT）；服务端须用 ListenConfig.Control 在 socket 创建时配置，客户端连接后立即设置；KeepAlive 仅探测链路可达性，须与应用层心跳协同。
Go 的 SetKeepAlive 默认不生效，必须手动开启
Go 的 net.Conn 接口本身不暴露 KeepAlive 控制权，底层 syscall.Socket 级别默认关闭该选项。即使你调用 conn.SetKeepAlive(true)，若未同时设置 SetKeepAlivePeriod（或等效方式），系统仍按内核默认值（Linux 通常为 2 小时）触发探测，几乎无法满足业务保活需求。
实操建议：
- 服务端和客户端都需显式启用并配置周期，不能只设
true - 使用
net.ListenConfig配合Control函数在监听前设置 socket 选项（服务端） - 客户端连接后立即对
net.Conn调用SetKeepAlive和SetKeepAlivePeriod - 注意：Go 1.11+ 才支持
SetKeepAlivePeriod；旧版本需用SetKeepAlive+syscall.SetsockoptInt手动设TCP_KEEPINTVL/TCP_KEEPIDLE
ListenConfig.Control 是服务端设 KeepAlive 的唯一可靠入口
直接对 listener.Accept() 返回的 conn 设置 keepalive 有竞态风险——连接刚建立、还没来得及调用 set 方法就被丢弃或复用。正确做法是在 socket 创建后、绑定前通过 ListenConfig.Control 注入系统级配置。
常见错误现象：服务端日志显示连接“静默断开”，但客户端没收到 RST，抓包发现无任何 TCP keepalive 包发出。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 用
net.ListenConfig{Control: func(fd uintptr) { ... }}获取原始 fd - 在 control 函数里用
syscall.SetsockoptInt设置TCP_KEEPIDLE（首次探测延迟）、TCP_KEEPINTVL（重试间隔）、TCP_KEEPCNT（最大失败次数） - Linux 下单位是秒；macOS/BSD 下
TCP_KEEPALIVE对应的是 idle 时间，且无KEEPINTVL，行为不一致 - 不要依赖
net.Listen("tcp", addr)的默认行为，它绕过了 Control 流程
客户端 SetKeepAlivePeriod 的时间单位易被误读
Go 文档写“duration since last data packet”，但实际生效逻辑取决于操作系统：Linux 会把传入的 time.Duration 直接转为秒填入 TCP_KEEPIDLE，而 macOS 把它当作 TCP_KEEPALIVE 值（即 idle 时间），且不支持单独设 interval。
使用场景：IM 心跳超时设为 30 秒，但发现连接 5 分钟才断开，就是因传了 30 * time.Second 却被系统当 idle 用了，而 interval 仍走默认 75 秒。
实操建议：
- 跨平台项目务必做 OS 判断，Linux 可设三元组，macOS 只能设 idle，Windows 行为接近 Linux 但需验证
- 测试时用
ss -i（Linux）或lsof -i -T（macOS）确认 socket 实际 keepalive 参数 - 避免用
time.Minute这类大值作保活周期，多数 NAT 设备在 60–180 秒无流量后就会回收映射表
KeepAlive 不等于应用层心跳，二者必须配合
TCP KeepAlive 只能探测链路是否“物理可达”，无法感知对端进程是否卡死、协程阻塞、或防火墙策略变更导致 ACK 被丢弃。单纯依赖它，可能连接已不可用，但 Go 程序还一直往里写数据，直到 write timeout 或对方 FIN 才察觉。
性能影响：KeepAlive 探测包极小（纯 ACK），基本无带宽压力，但频繁探测（如设成 5 秒）会增加内核 socket 状态检查负担，尤其高并发场景下。
实操建议：
- KeepAlive 周期建议 ≥ 30 秒，应用层心跳（如 WebSocket ping/pong）设为 10–15 秒，早于 KeepAlive 触发，主动踢掉异常连接
- 对写操作加 context 超时，避免
Write卡住整个 goroutine - 遇到
read: connection reset by peer或write: broken pipe后，不要重用 conn，立即关闭重建
KeepAlive 参数在不同系统上语义不统一，加上 Go 对底层 socket 的封装层级较深，最容易被忽略的是控制权不在 Conn 接口本身，而在 ListenConfig 或 syscall 层——没进到那层，就永远调不对。
