因为WebSocketHandler.ping()仅发送底层Ping帧，不触发on_message()回调，服务端无法确认响应、无法更新活跃时间、也无法实现超时断连；可靠心跳需基于write_message()与on_message()构建可追踪、可超时、可重置的双向应用层信号。
为什么 WebSocketHandler.ping() 不能直接当心跳用
因为 ping() 只是发一个 WebSocket ping 帧，不触发应用层回调，服务端收不到响应确认，也无法感知连接是否真通。真正的心跳必须是「可追踪、可超时、可重置」的双向信号。Tornado 的 WebSocketHandler 没有内置心跳状态管理，得自己搭骨架。
如何用 self.write_message() + on_message() 实现可靠心跳
核心思路：客户端定时发 {"type": "ping"}，服务端收到后立刻回 {"type": "pong"}，并刷新该连接的最后活跃时间；服务端另起一个协程，定期扫描所有连接，对超时未更新时间的连接主动调用 close()。
- 在
open()中记录连接时间：self.last_active = time.time() - 重写
on_message()，识别ping并立即回pong：if data.get("type") == "ping": self.write_message({"type": "pong"}) - 在
open()后启动后台心跳检查协程（用asyncio.create_task()），每 5 秒遍历所有活跃连接，对time.time() - conn.last_active > 15的连接执行conn.close(code=4001, reason="heartbeat timeout") - 务必在
on_close()中清理该连接的引用（比如从全局set或dict中移除），否则内存泄漏且检查协程会持续访问已销毁对象
set_nodelay(True) 和 max_message_size 对长连接稳定性的影响
高频心跳下，TCP Nagle 算法会攒包，导致 pong 延迟升高甚至卡住；同时小消息频繁发送可能触发默认的 10MB 消息上限误判。这两个配置必须显式调整：
- 在
open()中调用self.stream.set_nodelay(True)，禁用 Nagle，让每个write_message()立即发出 - 在 Tornado 应用初始化时传入
websocket_ping_interval和websocket_ping_timeout参数（仅影响底层 ping/pong 帧，不影响业务心跳） - 若心跳消息统一走 JSON 字符串，建议在构造
Application时设置websocket_max_message_size=64 * 1024（64KB 足够，避免默认值过大占用内存）
为什么不能依赖 websocket_ping_interval 做业务层心跳
Tornado 的 websocket_ping_interval 发的是底层 WebSocket ping 帧，它只保证 TCP 连通性，不经过 on_message()，无法携带业务上下文（如用户 ID、设备指纹），也不能被客户端精确响应——很多前端库（如 Socket.IO 客户端）根本不会处理原生 ping 帧，或将其与业务心跳混为一谈，造成误判。
立即学习“Python免费学习笔记（深入）”；
更关键的是：这个参数控制的是服务端单向发 ping 的节奏，但不校验 pong 是否回来，也不提供超时回调。一旦网络抖动丢了一个 pong，服务端毫无感知，直到下一次 ping 超时（默认 30 秒），远超业务要求的 15 秒断连阈值。
真实场景里，心跳逻辑必须和业务消息共用同一套序列化、同一套连接生命周期管理，否则调试时你会看到「连接明明还在收发业务消息，却被底层 ping 判定为断开」这种诡异现象。
