直播间的实时能力如果只靠前端定时请求接口，很快会遇到边界。

评论需要及时出现，在线状态需要更新，房间状态可能变化，运营希望看到实时反馈。轮询能撑一段时间，但当互动和在线统计都变成核心体验时，它会让前端、后端和数据库都变得紧张。

实时不是为了炫技

我不会为了“用了 WebSocket”而做实时能力。直播间需要实时，是因为用户体验和运营判断都依赖它。

评论晚几秒出现，用户会觉得互动不顺；在线人数不准，运营会误判直播热度；房间状态更新不及时，观看端可能继续停留在错误页面。

这些问题本质上不是 UI 问题，而是事件传播问题。

事件要有边界

直播系统里并不是所有数据都应该实时推送。房间配置、用户资料、历史记录可以走普通接口；评论、新消息、房间状态和在线变化更适合事件。

我在设计这类能力时，会先区分哪些是状态查询，哪些是事件通知。状态查询强调准确，事件通知强调及时。两者混在一起，系统会变得很难排查。

Presence 是业务概念

Presence 看起来是技术能力，但在直播间里它会变成业务概念。

谁进入了房间，谁离开了，多久没有心跳，是否还算在线，这些都影响在线人数和运营统计。只把它看成连接数，会漏掉很多业务细节。

我更愿意把 Presence 当成“观看状态”来设计。连接只是信号之一，心跳、缓存、过期清理和房间维度都要一起考虑。

后台也需要实时反馈

实时能力不只服务观看端。后台运营也需要知道直播间状态、评论情况和在线变化。

如果后台只能手动刷新，运营就很难及时判断问题。实时事件进入后台后，运营人员能更早看到直播是否正常，评论是否活跃，在线人数是否异常。

这会让直播系统从“能播”变成“能运营”。

实时能力最后要回到稳定性

直播间实时能力的价值，不在于技术栈名字，而在于稳定。

事件不能乱发，连接不能无限占用资源，离线状态要能清理，评论和在线统计要能解释。只要这些基础不稳，实时越多，问题越多。

所以我做直播实时能力时，会把它看成一套系统能力：事件模型、连接管理、缓存状态、后台反馈和故障排查要一起设计，而不是只加一个推送通道。