实时通信与 WebSocket 测试：连接生命周期、消息时序、断线重连与并发压测
系统讲解实时通信与 WebSocket 测试的工程化实践：连接生命周期（握手升级、鉴权、心跳保活、优雅关闭）验证、消息顺序与乱序/重复/丢失的至少一次语义、背压与缓冲控制、断线重连的退避与状态恢复、重连风暴防护、连接数与广播的并发压测、mock WebSocket 服务端与录制回放，以及 CI 中的稳定性治理。
tag
断线重连
共 5 篇文章。
《AI Agent 工程实战》9.3 断线重连：Last-Event-ID 续传不丢步
SSE 断线后客户端带 Last-Event-ID 重连，服务端从该 id 之后续推，呼应 3.2 的事件 id。讲清为什么必须服务端保留事件缓冲、缓冲多久、缓冲丢了怎么降级为全量重取；用 httpx 真跑「消费 5 条断开 → 重连补齐 11 条」并断言无重复无缺失。
《TypeScript编程实战》10.3 心跳、重连与广播
长连接上线前还有三块拼图没补齐：它会静默假死、断了要能自动恢复、单实例的订阅表在多副本部署下会失效。本节先讲清心跳为什么必须由应用层承担、ping/pong 与业务保活如何配合、指数退避加抖动如何避免重连风暴，再讲断线后的状态补偿与消息幂等，最后用 Redis 发布订阅把广播从单机扩展到集群，并给出背压、慢消费者与可观测性的落地方案。
Godot 断线重连后的世界重同步：连上服务器不等于能立刻继续玩
重连成功只是第一步 socket 重新连上只代表可以通信，断线期间世界已经继续变化。这个问题在项目早期经常被当成小功能，等内容量、平台数量和运营节奏上来之后才暴露成本。Godot 客户端要做的不是写一个临时脚本，而是把它当成可验证、可回滚、可观测的系统来设计。团队需要知道数据从哪里来，谁有权修改，失败后玩家看到什么。
游戏在线状态目录服务架构设计
围绕玩家在线状态、会话归属、断线重连、跨服查询与好友展示，设计一个可靠的游戏 Presence 与 Session Directory 架构。