go应用层心跳包不能用json或带换行字符串，因中间设备会静默丢弃含空格、引号、冒号等“非标准”字符的流量；应使用固定长度、全大写、无分隔符的裸字节（如"ping"），并通过io.readfull精确读取，配合readdeadline重置与双向验证确保可靠性。
Go应用层心跳包为什么不能用JSON或带换行的字符串
因为中间网络设备（如企业NAT、云防火墙、代理网关）会静默丢弃“非标准协议”流量。你发一个 {"type":"ping","ts":"2026-05-23T05:10:00Z"}，它可能含空格、双引号、冒号、花括号——某些设备会直接判定为非法协议而断连；加 \n 更危险，容易被当成粘包边界误切。真要保活，心跳必须是无状态、无结构、无编码开销的裸字节。
常见错误包括：
- 用
json.Marshal生成心跳内容 - 在心跳包末尾加
\n或\r\n试图“对齐协议” - 混用大小写，比如客户端发
PING，服务端只认ping
正确做法是固定长度、全大写、无分隔符：PING（4字节）、PONG（4字节）。不依赖任何解析逻辑，bytes.Equal(buf[:4], []byte("PING")) 就能判断。
如何安全读取并识别心跳包（避免粘包/截断）
TCP 是字节流，你不能假设每次 conn.Read 都刚好读到一个完整心跳包。如果协议没帧头帧尾、没长度域，又不做缓冲处理，就极易把 PINGPONG 读成两个 PING，或把 PING 拆成两次读（如第一次读到 PI，第二次才读到 NG）。
推荐轻量级解包策略：
- 心跳包统一固定长度（如 4 字节），读取时用
io.ReadFull(conn, buf[:4])，它会阻塞直到填满或出错 - 不要用
bufio.Scanner或ReadString('\n')，它们依赖分隔符，而心跳不该有分隔符 - 若必须支持变长心跳（极不推荐），至少加 1 字节长度前缀，先读 1 字节得长度
n，再读n字节 - 读完后立刻重设
conn.SetReadDeadline(time.Now().Add(25 * time.Second))，否则下次读会沿用旧 deadline
服务端收到 PING 后，为什么不能只 Write("PONG") 就完事
只发 PONG 不等于心跳响应成功。如果对方连接已半关闭（比如客户端崩溃但 TCP FIN 还没传到），Write 可能成功返回（内核缓冲区还能写），但实际数据永远发不出去。真正可靠的响应必须触发一次可验证的回路：服务端发 PONG → 客户端收到 → 客户端立刻更新本地 lastActive 时间戳。
关键动作是双向确认：
- 服务端收到
PING后，应调用conn.Write([]byte("PONG"))，但不检查其返回值是否成功（Write 成功 ≠ 对端收到） - 客户端发完
PING后，必须紧接着Read等待PONG，且设置比心跳间隔更长的 deadline（如心跳 20s，Read 超时设 25s） - 只有 Read 返回
io.EOF、net.OpError（timeout / connection refused）或明确bytes.Equal(buf, []byte("PONG")) == false，才标记连接失效
漏掉 Read 验证，等于只做了单向探测，和没发心跳没区别。
gorilla/websocket 的 Ping/Pong 和自定义 TCP 心跳能混用吗
不能。WebSocket 协议的 PingMessage 和 PongMessage 是控制帧，走独立通道，由底层库自动处理（比如 SetPongHandler 注册回调），不经过你的应用层 Read/Write 流程。而自定义 TCP 心跳是业务字节流，混在一起会导致协议错乱：比如你手动发 PING 字符串，WebSocket 库可能把它当普通文本消息解析，触发 SetMessageHandler，甚至因格式不符报错。
正确隔离方式：
- 用 WebSocket 就彻底放弃自定义 TCP 心跳，只用
conn.WriteMessage(websocket.PingMessage, nil)+SetPongHandler - 用裸 TCP 就别引入
gorilla/websocket，从net.Conn开始自己控协议 - 若强行桥接（如 TCP 上跑 WebSocket 子协议），心跳必须严格遵循 RFC 6455，不能用任意字符串
最易踩的坑是：以为 “都叫 Ping” 就可以复用逻辑，结果调试三天发现心跳帧被库吞了、没进业务 handler、也没触发超时——因为根本不在同一个协议层。
