Appearance
WebSocket、SSE 与轮询：实时通信的连接模型
主题定位
实时通信方案的差异不在名字，而在连接方向、状态保持和基础设施兼容性。
- 实时通信方案的差异不在名字，而在连接方向、状态保持和基础设施兼容性
- 实时通信方案选择的核心是：谁向谁推送、连接保持多久、消息方向是单向还是双向，以及基础设施是否支持
- WebSocket、SSE、长轮询各自适配不同实时性、复杂度和兼容性场景
- 并不是所有“实时”都值得上 WebSocket，通知流、日志流和进度流很多时候用 SSE 更轻
实时通信方案拆分
轮询
轮询 先看职责边界，再看生命周期、数据形态和与其他对象的协作关系。 轮询 的差异最终会体现在 协议语义、连接代价、失败恢复 这几个维度。 轮询 讲清适用边界、失效条件和代价结构，结论才有技术含量。
SSE
SSE 先看职责边界，再看生命周期、数据形态和与其他对象的协作关系。 SSE 的差异最终会体现在 协议语义、连接代价、失败恢复 这几个维度。 SSE 讲清适用边界、失效条件和代价结构，结论才有技术含量。
WebSocket
WebSocket 先看职责边界，再看生命周期、数据形态和与其他对象的协作关系。 WebSocket 的差异最终会体现在 协议语义、连接代价、失败恢复 这几个维度。 WebSocket 讲清适用边界、失效条件和代价结构，结论才有技术含量。
能力对照与适用场景
- 实时通信方案的差异不在名字，而在连接方向、状态保持和基础设施兼容性
- 实时通信方案选择的核心是：谁向谁推送、连接保持多久、消息方向是单向还是双向，以及基础设施是否支持
- WebSocket、SSE、长轮询各自适配不同实时性、复杂度和兼容性场景
- 并不是所有“实时”都值得上 WebSocket，通知流、日志流和进度流很多时候用 SSE 更轻
- 短轮询通过周期性请求换取近实时更新，实现最简单，但请求开销大、延迟较高
- 长轮询会让请求挂起到有数据或超时后再返回，减少空轮询成本，但仍是请求-响应模型
选型建议与约束
- 实时通信方案的差异不在名字，而在连接方向、状态保持和基础设施兼容性
- 实时通信方案选择的核心是：谁向谁推送、连接保持多久、消息方向是单向还是双向，以及基础设施是否支持
- WebSocket、SSE、长轮询各自适配不同实时性、复杂度和兼容性场景
- 并不是所有“实时”都值得上 WebSocket，通知流、日志流和进度流很多时候用 SSE 更轻
- 短轮询通过周期性请求换取近实时更新，实现最简单，但请求开销大、延迟较高
问答设计及延伸
标准回答
回答 WebSocket、SSE 与轮询：实时通信的连接模型 时，先定义 轮询、SSE、WebSocket 各自解决的问题，再比较它们在 协议语义、连接代价、失败恢复 上的差异，最后给出选型边界和工程代价。
追问拆解
- WebSocket、SSE 与轮询：实时通信的连接模型 与“HTTP 版本演进：1.1、2、3 的连接模型与代价”的边界关系
- WebSocket、SSE 与轮询：实时通信的连接模型 与“超时、重试与幂等：接口治理中的失败恢复”的边界关系
- WebSocket、SSE 与轮询：实时通信的连接模型 与“多标签页通信：storage、BroadcastChannel、SharedWorker 与一致性”的边界关系
- 跨标签页、跨域、多端协作场景下的结论变化
- 维护成本上升后的优先级调整
容易失分的点
- 只给“哪个好”的结论，不先拆对象
- 只报 API 或术语，不解释运行时行为和代价
- 缺少真实场景，导致结论过度绝对
项目映射
- 结合真实系统说明 轮询 到 WebSocket 分别落在哪段链路
- 补充未选方案的放弃原因和约束差异
- 补充线上问题、治理动作和验证结果