群聊系统中新消息websocket事件应由客户端还是API接口触发？

两种触发方案选型结论 #

优先选择方案1（服务端api.com/message-create接口触发推送），方案2仅适合极特殊的弱网离线优先场景，普通群聊不要用。

方案1核心优势 #

• 一致性强：所有消息事件以服务端持久化到数据库的结果为准，完全不会出现发送方本地显示消息成功，但实际接口因为网络波动、权限不足、内容违规被拦截等原因请求失败，导致的群成员消息不一致问题。
• 逻辑统一：所有群成员（包括发送方自己）的消息都走同一条推送链路，不需要给发送方单独做本地消息的特殊渲染，后续加敏感词过滤、@提醒、撤回、消息统计等功能只需要在服务端修改一次即可。
• 安全性高：所有消息都是服务端校验通过后才推送，不存在客户端伪造假消息刷群的风险。

方案2的核心问题 #

• 有一致性硬伤：如果接口调用失败，发送方已经本地展示了消息，其他群成员收不到，你需要额外做消息回滚、失败重试、错误提示等复杂逻辑，还很容易出现消息时序错乱。
• 维护成本高：发送方的消息展示和其他群成员走不同链路，后续迭代功能需要两端同步修改，容易出bug。
• 安全风险高：客户端可以随意构造消息事件推送到通道，服务端如果做全量校验相当于重复实现方案1的逻辑，浪费性能，不做校验就会出现大量伪造垃圾消息。

WebSocket通道相关问题解答 #

• 两种方案本身不会带来WebSocket通道数量的差异：WebSocket是每个客户端和服务端建立一条长连接，不管消息事件是客户端发起推送还是服务端发起推送，都不会额外增加通道数量，只要你没有为不同类型的事件单独建连接，就不会多占通道资源。
• 全局单通道完全可以满足绝大多数群聊场景的需求：

  单条WebSocket连接的承载能力取决于单条消息大小和推送频率，普通文本消息单条仅几KB，单通道每秒处理上百条推送没有压力，只要不是万人以上超大群持续刷屏的场景，全局单通道完全够用。
  如果后续遇到性能瓶颈，优先做消息削峰填谷、非重要消息合并推送优化即可，拆分多条通道只会额外增加服务端连接管理的复杂度，收益极低。

内容的提问来源于stack exchange，提问作者kaname-png