📊 对比表
| 对比维度 | 普通轮询（Polling） | WebSocket |
|---|---|---|
| 实时性 | ⏳ 一般（延迟=轮询间隔） 例如 5 秒轮询，平均延迟 2.5 秒 | ⚡️ 高（消息可毫秒级送达） |
| 数据库压力 | 🚨 高（每次轮询都可能查数据库，尤其是无新消息也查） | ✅ 极低（仅有新消息时触发推送） |
| 服务器 QPS | 🚨 高（大量重复无效请求） 例如 100 人 5 秒轮询 = 20 QPS | ✅ 低（只维持长连接，无空请求） |
| 网络带宽消耗 | ❌ 浪费（频繁 HTTP 请求 + 无效负载） | ✅ 高效（仅必要数据推送） |
| 连接资源（内存） | ✅ 少（短连接） | ⚠️ 较高（每个用户维持一个长连接） |
| 实现复杂度 | ✅ 简单（HTTP 接口即可） | ⚠️ 中等（需要连接管理、心跳、消息推送） |
| 浏览器兼容性 | ✅ 100%（所有环境支持） | ✅ 广泛支持（IE10+、移动端均支持） |
| 可扩展性 | ❌ 差（用户增多后服务器压力急剧增加） | ✅ 强（结合 Redis Pub/Sub 可水平扩展） |
| 消息可靠性 | ❌ 差（轮询间隔期间可能漏感知） | ✅ 高（实时送达，可确认） |
| 移动端支持 | ❌ 不省电（后台频繁唤醒） | ✅ 更省电（后台维持连接或推送） |
🎯 场景建议
| 场景 | 推荐方案 |
|---|---|
| ✅ 用户量小（<50人），部署简单优先 | 普通轮询即可 |
| ✅ 中型用户量（约 100 人），需聊天实时性 | 推荐使用 WebSocket |
| ✅ 用户量大或计划扩展 | WebSocket + Redis Pub/Sub 架构 |
| ✅ 快速上线 MVP 原型 | 可先用轮询，后期平滑切换为 WebSocket |