这是《在线联机原型全集》的第一站，也是整部合集里唯一一个「不为了好玩」而写的原型。聊天室本身没有胜负、没有积分、没有地图，它存在的意义是把所有后续章节都要复用的那一层底座——连接、身份、状态、消息、广播、心跳、恢复——先用最小代价跑通。如果你准备从第 2 章的匹配系统一路读到第 60 章的永续世界，请务必先在这里把「一条消息如何往返」这件事彻底搞清楚，否则后面每一个原型的调试都会变成盲人摸象。
本章定位
- 难度梯度：入门级，全书起点。本章不涉及同步、回滚、AOI、结算等任何进阶概念，只关心「通道是否可靠」。
- 前置章节：无。本章是 60 章依赖链的根节点，
proto-001-echo-chatroom会被后续几乎所有原型标注为「依赖模块」。 - 能力跃迁：从「HTTP 请求-响应」的短连接思维，切换到「长期驻留的双向通道」思维。这一步跨不过去，后面的实时对战章节会完全读不懂。
- 阅读时长：单篇 PRD 约 400 至 500 行，建议配合一份最小 WebSocket 服务端实现同步动手。
核心验证目标
本章 PRD 的功能目标表把验证点拆成了七个类别，提炼如下：
- 连接层：WebSocket over HTTPS 的握手、Ping/Pong 心跳、往返延迟监测与超时踢出。
- 鉴权层：连接建立之前完成身份校验，采用 JWT 或 OAuth2 Token，拒绝匿名长连接。
- 会话层：Session Manager 管理在线用户与连接上下文，支持同一用户多端登录时的策略选择。
- 房间层：Room Service 负责创建、加入、退出与成员列表同步，房间与连接解耦。
- 消息层：Message Dispatcher 保证消息的有序性、幂等性与反复验证能力，区分文本、表情、系统通知等类型。
- 广播层：以 Redis Pub/Sub 做跨实例扇出，为后续多进程水平扩展预留接口。
- 容错与观测：网络抖动后的自动重连与消息流恢复，连接数、消息量、错误率三类指标落盘。
技术栈建议
- 语言：Go、Node.js 或 Rust 任一即可。Go 的 goroutine 模型对「一连接一协程」最直观，是本章最省心的选择。
- 传输：WebSocket over HTTPS，消息体先用 JSON 打通，二进制帧留到第 5 章再引入。
- 扇出：Redis Pub/Sub 承担广播通道，本章只用到最基础的频道订阅，不涉及 Stream 与持久化。
- 鉴权：JWT 为主，OAuth2 作为可替换实现。
- 观测：连接数与消息量指标，建议一开始就用 Prometheus 风格的计数器埋点，后面第 49 章的 AI 运维检测会直接复用。
本章文章
| 文章标题 | 核心内容 |
|---|---|
| 在线联机原型全集：第 1 章 聊天室（Echo Chatroom） | 完整 PRD：Gateway、Session Manager、Room Service、Message Dispatcher 四模块拆分，附消息类型定义、心跳参数与断线恢复流程 |
本章目前只有这一篇 PRD，没有拆分出独立的设计稿或算法专题，原因是底座的复杂度不足以支撑第二篇文章；从第 11 章开始，章节才会普遍出现「PRD + 设计详解」的双篇结构。
与相邻章节的关系
- 下一章：第 2 章 石头剪刀布 在本章的通道之上叠加匹配队列与锁步回合，是「通道可用」迈向「玩法可用」的第一步。
- 父级入口：产品原型开发专题 给出全 60 章的路线图与分阶段阅读建议。