WebSockets+React开发是否应使用单连接承载多类实时功能？

你把WebSocket实例存入React Context全局复用、避免重复建连的思路是对的。单条WebSocket连接完全可以承载多类实时业务，结合你当前使用的AWS API Gateway + Lambda无服务器架构，绝大多数场景下没必要额外拆分独立的Socket API，单连接方案反而更省成本、运维复杂度更低。

单连接承载多业务的落地方式 #

你只需要在消息协议层做业务路由区分即可，不需要改动连接层逻辑：

• 前后端约定统一的消息结构，所有上行、下行消息都携带action字段标识业务类型，比如chat_message对应聊天消息、user_status_change对应在线状态同步、system_notice对应站内通知推送。后端收到消息后根据action字段分发到对应业务逻辑处理即可，不需要为不同业务维护独立连接。
• 前端在Context层做统一的消息分发：连接建立后只绑定一个原生onmessage监听，收到消息先解析action字段，再分发给各业务模块提前注册的回调。不要让各个业务组件直接操作socket实例绑定事件，避免回调冲突、内存泄漏问题。
• 可以直接复用API Gateway WebSocket自带的路由键能力，在网关层就根据消息里的action配置路由规则，把不同类型的消息转发到对应的独立Lambda函数处理，不需要写单体大Lambda承接所有逻辑，做到连接复用的同时保持业务逻辑解耦。

统一消息格式可以参考这个示例：

{
  "action": "chat_message",
  "payload": {
    "conversationId": "c_10086",
    "content": "测试消息",
    "senderId": "u_2001"
  },
  "requestId": "a7f3d92e-1c4b-4f8a-9d3e-7b6c5a4d3e2f"
}

需要拆分独立连接的特殊场景 #

只有碰到以下几类情况时，再考虑拆分独立的WebSocket API：

• 鉴权体系完全隔离：比如面向C端用户的实时功能、面向内部运营后台的实时功能使用两套完全独立的权限校验逻辑，共用连接存在鉴权穿透的安全风险。
• 消息量级差异悬殊：比如某类业务是高频大流量推送（比如每秒多次的实时IoT设备数据、实时行情数据），和低频次的聊天、状态同步共用连接时，大流量消息会阻塞队列，影响核心轻量业务的实时性。
• 合规强制隔离：涉及金融交易、敏感健康数据等有强合规要求的实时传输场景，规则要求必须和普通业务链路做物理隔离。

React + AWS无服务器栈的落地注意点 #

• 用useRef存储WebSocket实例，不要直接把实例放到Context的普通状态值里，避免组件重渲染触发连接意外重建，和业务相关的消息数据再通过Context或状态管理工具下发给组件。
• 在Context顶层统一实现心跳保活、断开重连逻辑，不要在各个业务模块里单独写重连逻辑，避免出现多连接并发的问题。注意AWS API Gateway WebSocket默认空闲连接超时时间是10分钟，心跳包间隔要设置在10分钟以内，避免连接被服务端主动掐断。
• Lambda本身是无状态的，你不需要在服务端维护连接和业务的绑定关系，直接调用API Gateway提供的@connections接口向指定连接ID推送消息即可，单连接下多业务的消息推送不会互相干扰。

内容的提问来源于stack exchange，提问作者Red Vic