Go 的 net/rpc/jsonrpc 不兼容浏览器原生 WebSocket，因其底层期望裸 TCP 流而非 WebSocket 帧；需改用自定义 WebSocket Codec 或协议适配层，才能让浏览器通过 new WebSocket() 安全发起 JSON-RPC 调用。
go 的 `net/rpc/jsonrpc` 不兼容浏览器原生 websocket，因其底层期望裸 tcp 流而非 websocket 帧；需改用自定义 websocket codec 或协议适配层，才能让浏览器通过 `new websocket()` 安全发起 json-rpc 调用。
你遇到的问题本质是协议语义错位：浏览器使用标准 WebSocket 协议（RFC 6455）建立连接并发送 JSON-RPC 格式的消息帧，而 jsonrpc.ServeConn(ws.UnderlyingConn()) 实际接管的是 WebSocket 底层的 net.Conn，并期望接收原始、无帧头的 JSON-RPC 字节流（即 JSON-RPC over raw TCP）。但 ws.UnderlyingConn() 在 gorilla/websocket 中并非真正的裸 TCP 连接——它已被 WebSocket 协议栈封装/解包，直接传给 jsonrpc.ServeConn 会导致协议解析失败，服务端在读取第一个“帧”时即触发错误（如 io: read/write on closed pipe 或 websocket: close 1006），随即关闭连接，因此你完全看不到 RPC 方法被调用的日志。
✅ 正确解法：实现 WebSocket-aware ServerCodec
要使浏览器 WebSocket 客户端与 Go net/rpc 无缝协作，必须绕过 jsonrpc.ServeConn，转而构建一个 WebSocket 原生的 RPC 编解码器（ServerCodec），它能：
- 在 ReadRequestHeader / ReadRequestBody 中主动从 *websocket.Conn 读取完整 JSON-RPC 请求帧（ReadMessage）；
- 解析 JSON-RPC 2.0 请求结构（含 method, params, id）；
- 将 params 反序列化为 Go 结构体，并注入连接上下文（如远程地址、header）；
- 在 WriteResponse 中将响应按 JSON-RPC 2.0 格式序列化后，通过 WriteMessage 发送回客户端。
以下是一个轻量、生产可用的实现示例：
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
// websocket_codec.go
package main
import (
"context"
"encoding/json"
"net/rpc"
"net/rpc/jsonrpc"
"reflect"
"github.com/gorilla/websocket"
)
type WebSocketCodec struct {
conn *websocket.Conn
}
func NewWebSocketCodec(conn *websocket.Conn) *WebSocketCodec {
return &WebSocketCodec{conn: conn}
}
func (c *WebSocketCodec) ReadRequestHeader(r *rpc.Request) error {
_, data, err := c.conn.ReadMessage()
if err != nil {
return err
}
var req struct {
JSONRPC string `json:"jsonrpc"`
Method string `json:"method"`
Params interface{} `json:"params"`
ID interface{} `json:"id"`
}
if err := json.Unmarshal(data, &req); err != nil {
return err
}
r.ServiceMethod = req.Method
r.Seq = uint64(0) // Seq unused in HTTP/WebSocket mode; ID handled in body
return nil
}
func (c *WebSocketCodec) ReadRequestBody(x interface{}) error {
_, data, err := c.conn.ReadMessage()
if err != nil {
return err
}
return json.Unmarshal(data, x)
}
func (c *WebSocketCodec) WriteResponse(r *rpc.Response, body interface{}) error {
resp := map[string]interface{}{
"jsonrpc": "2.0",
"result": body,
"id": r.Seq, // Note: real impl should track ID from request
}
data, _ := json.Marshal(resp)
return c.conn.WriteMessage(websocket.TextMessage, data)
}
func (c *WebSocketCodec) Close() error {
return c.conn.Close()
}
? 服务端集成（修正 serveWS）
func serveWS(w http.ResponseWriter, r *http.Request) {
ws, err := upgrader.Upgrade(w, r, nil)
if err != nil {
log.Println("Upgrade failed:", err)
return
}
defer ws.Close() // Ensure cleanup on exit
// 使用自定义 Codec 替代 jsonrpc.ServeConn
codec := NewWebSocketCodec(ws)
server := rpc.NewServer()
server.RegisterName("Service", new(Service))
server.ServeCodec(codec)
}
? 浏览器端注意事项（index.html 补充）
你的前端 JSON-RPC 请求需严格遵循 JSON-RPC 2.0 规范（推荐）：
function send() {
const msg = {
jsonrpc: "2.0",
method: "Service.Echo",
params: ["hello"], // 注意：params 必须是数组（即使单参数）
id: Date.now() // 非零值，用于匹配响应
};
ws.send(JSON.stringify(msg));
}
同时，监听响应时应解析 id 和 result 字段：
ws.onmessage = function(ev) {
const resp = JSON.parse(ev.data);
if (resp.id && resp.result !== undefined) {
alert("Response: " + resp.result);
}
};
⚠️ 关键注意事项
- ❌ 不要再调用 ws.UnderlyingConn() —— 它在 WebSocket 升级后已不可靠，且违反协议分层；
- ✅ 必须手动管理 *websocket.Conn 生命周期：ServeCodec 返回后需确保 Close() 被调用（上述 defer ws.Close() 位置错误，应移至 ServeCodec 调用之后或使用 context 控制）；
- ? net/rpc/jsonrpc 包本身不支持 WebSocket 传输层，这是设计限制，非 bug；强行桥接需完全替换编解码逻辑；
- ? 若需获取客户端 IP 或 header，请在 serveWS 中将 r.RemoteAddr 或 r.Header 注入 context.Context，再通过反射注入到 Args.Context 字段（参考知识库中 WebSocketContextCodec 方案）；
- ? 性能提示：每个 WebSocket 连接对应一个独立 rpc.Server 实例或共享 rpc.DefaultServer，注意并发安全（rpc.Server 是线程安全的）。
通过以上改造，你的浏览器即可像调用任意 WebSocket API 一样，与 Go 后端完成标准 JSON-RPC 2.0 交互，既保持协议兼容性，又规避了底层网络抽象泄漏风险。
