go-jsonrpc已停止维护，官方推荐迁移到net/rpc或grpc；旧版对content-type、路径、json格式敏感，不支持batch和context，方法需导出且参数必须为具体结构体，错误需手动填充，并发batch请求会panic。
go-jsonrpc 已停止维护，官方推荐迁移到 net/rpc 或更现代的 gRPC；若项目中已引入旧版 go-jsonrpc（如 github.com/ethereum/go-ethereum/rpc 的早期 fork），需特别注意其与标准 JSON-RPC 2.0 协议的兼容性缺口。
为什么调用总返回 Parse error 或 Invalid Request
旧版 go-jsonrpc 默认只接受 Content-Type: application/json，且对空 body、换行符、多余空格敏感；它不自动处理 POST / 路径外的路由，也不支持批量请求（batch）解析。
- 确保客户端发送的请求体是紧凑 JSON（无首尾空格、无换行），例如：
{"jsonrpc":"2.0","method":"echo","params":["hello"],"id":1} - 服务端必须监听
/路径，其他路径（如/rpc）会导致 404 或静默失败 - 避免在请求头中设置
Content-Type: application/json; charset=utf-8—— 多余的charset参数会被拒绝
如何注册方法并支持 context 透传
原生 go-jsonrpc 不支持 context.Context 参数，所有 handler 签名只能是 func(*T, *Args, *Reply) error。若需超时或取消控制，必须在 Args 结构体中手动嵌入字段（如 TimeoutMs int），并在 handler 内部构造 context.WithTimeout。
- 方法名必须导出（首字母大写），且结构体字段也需导出，否则序列化为空
- 不能直接传指针类型作为
Args或Reply，必须是具体结构体类型 - 错误返回值不会自动转为 JSON-RPC 的
error.code和error.message，需手动填充Reply.Error字段或 panic（不推荐）
客户端调用时为什么一直卡住或返回 EOF
常见于服务端未正确关闭连接或响应未写满。该库依赖底层 http.ResponseWriter 直接写入，若 handler panic 或提前 return 且未写响应，HTTP 连接会 hang 住，客户端最终超时或收到 EOF。
- 务必在每个 handler 中保证至少一次
json.NewEncoder(w).Encode(...)调用（即使返回空对象） - 不要在 handler 中调用
w.WriteHeader()——go-jsonrpc自动处理状态码，手动设置会干扰响应流 - 使用长连接时（
Keep-Alive），服务端需设置http.Server.ReadTimeout和WriteTimeout，否则连接可能滞留数分钟
真正麻烦的不是怎么写通一个调用，而是当多个客户端并发发来 batch 请求时，旧版 go-jsonrpc 会把整个数组当作单个 object 解析，直接 panic —— 这个问题没有修复补丁，只能前置拦截并拆包，或者换掉底层库。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
