websocket不是rpc而是其通信通道，真正的rpc由上层协议实现：客户端发送含方法名、参数和请求id的结构化消息，服务端解析执行并返回结果，双方通过id匹配响应；需显式注册函数白名单、封装调用接口并注意鉴权、消息大小、并发限制及wss加密。
WebSocket 本身不是 RPC，但它能为 RPC 提供理想的通信通道——持久、双向、低开销。真正实现远程调用的，是构建在 WebSocket 之上的 RPC 协议层：客户端把“想调什么函数、传什么参数”打包成结构化消息发过去，服务端解析、执行、返回结果，整个过程对调用方尽量透明。
明确角色分工：WebSocket 是管道，RPC 是协议
WebSocket 只负责建立并维持连接、收发原始字节或文本；它不关心你发的是 JSON 还是二进制，也不管你调的是 add() 还是 login()。真正的 RPC 行为由两端约定的规则来定义：
- 客户端发送的消息必须包含方法名（如 "user.login"）、参数列表（如 ["admin", "123456"]）和唯一请求 ID（用于匹配响应）
- 服务端收到后，根据方法名查表找到对应函数，用参数执行，再把结果（或错误）连同请求 ID 一起发回
- 客户端靠请求 ID 把响应匹配到对应的 await 或回调上，完成一次“像本地调用一样”的体验
服务端需注册可调用函数并处理消息路由
不能让 WebSocket 服务端直接暴露所有内部函数。安全且可控的做法是显式注册白名单函数，并统一入口处理 RPC 消息：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 用字典/Map 存储函数引用，比如 rpc_functions["calculate.sum"] = (a, b) => a + b
- 接收消息后先 JSON.parse，检查 method 字段是否存在、params 是否合规，再执行对应函数
- 捕获异常并返回标准错误格式（如 {"id": "...", "error": "Function not found"}），避免堆栈泄露
- 不建议在 RPC 函数里直接操作数据库或文件系统，应封装为业务服务层再被调用
客户端要封装调用逻辑，隐藏连接细节
用户不该每次调用都手动拼 JSON、管理 WebSocket 实例、写 onmessage 回调。应提供类似 rpc.call("user.getProfile", [123]) 的简洁接口：
- 内部自动生成唯一请求 ID，缓存 Promise 的 resolve/reject，等待对应 ID 的响应到来
- 自动重连机制：连接断开时暂停新请求，重连成功后清空旧缓存、重新同步状态（如有必要）
- 超时控制：每个 call 默认带 timeout，到期未收到响应则 reject 并清理缓存
- 如果服务端支持，可复用单个 WebSocket 连接并发多个 RPC 请求，无需为每次调用建新连接
注意实际部署中的关键约束
WebSocket RPC 看似简单，但上线后常因忽略底层特性而失败：
- HTTP 握手阶段可做鉴权（如校验 token 在 Sec-WebSocket-Protocol 或查询参数中），拒绝非法连接
- 消息体不宜过大（一般不超过几 MB），否则易触发浏览器或代理限制；大文件传输应改用 HTTP 分片或专用上传接口
- 服务端需限制单连接并发请求数和总内存占用，防止恶意客户端耗尽资源
- 生产环境务必启用 wss（WebSocket Secure），禁用 ws，否则中间人可窃听或篡改调用参数
