Gorilla JSON-RPC 返回空 result（如 "result": {}）通常是因为响应结构体中字段未导出（首字母小写），导致 JSON 编码器无法序列化；修复只需将字段名首字母大写，使其成为导出字段。
gorilla json-rpc 返回空 `result`（如 `"result": {}`）通常是因为响应结构体中字段未导出（首字母小写），导致 json 编码器无法序列化；修复只需将字段名首字母大写，使其成为导出字段。
在使用 Gorilla Toolkit 的 gorilla/rpc 实现 JSON-RPC 服务时，一个常见且隐蔽的陷阱是：自定义响应结构体返回空对象 {}，即使逻辑正确、赋值无误。根本原因并非网络、路由或方法签名问题，而是 Go 语言的 导出（exported）规则与 JSON 序列化机制的交互限制。
? 问题根源：Go 的导出规则决定 JSON 可见性
Go 要求：只有首字母大写的字段（即导出字段）才能被外部包（包括 encoding/json）访问和序列化。而 gorilla/rpc 在构建 JSON-RPC 响应时，底层依赖 json.Marshal 对 reply 参数进行编码。若结构体字段为小写（如 sum, message），它们被视为非导出字段，json.Marshal 会忽略它们，最终输出空对象 {}。
你原始代码中的 Response 定义：
type Response struct {
sum int // ❌ 非导出字段 → JSON 中不可见
message string // ❌ 同样不可见
}即使 reply.sum = 12 执行成功，json.Marshal(reply) 仍返回 {}。
✅ 正确写法：使用导出字段（首字母大写）
只需将字段名改为大驼峰命名，并保持类型一致即可：
type Response struct {
Sum int `json:"sum"` // ✅ 导出字段，可被 JSON 编码
Message string `json:"message"` // ✅ 同上
}完整可运行的服务端示例：
package main
import (
"log"
"net/http"
"github.com/gorilla/rpc/v2"
"github.com/gorilla/rpc/v2/json"
)
type Args struct {
A, B int `json:"A,B"`
}
type Response struct {
Sum int `json:"sum"`
Message string `json:"message"`
}
type Arith int
func (t *Arith) Add(r *http.Request, args *Args, reply *Response) error {
reply.Sum = args.A + args.B
reply.Message = "Do math"
return nil
}
func main() {
s := rpc.NewServer()
s.RegisterCodec(json.NewCodec(), "application/json")
s.RegisterService(new(Arith), "Arith")
http.Handle("/rpc", s)
log.Println("JSON-RPC server listening on :8080")
log.Fatal(http.ListenAndServe(":8080", nil))
}发起请求（如用 curl）：
curl -X POST http://localhost:8080/rpc \
-H "Content-Type: application/json" \
-d '{"method":"Arith.Add","params":[{"A":10,"B":2}],"id":1}'将得到预期响应：
{
"result": {"sum":12,"message":"Do math"},
"error": null,
"id": 1
}⚠️ 注意事项与最佳实践
- 字段标签（json:）非必需但推荐：即使不加 json:"sum"，Sum 也会默认序列化为 "sum"（Go JSON 包自动小写转换）。显式声明可增强可读性与控制力（如重命名、忽略字段等）。
- 避免混用大小写风格：不要在同一个结构体中部分字段大写、部分小写——会导致部分字段丢失，极难调试。
- reply 必须是指针类型：方法签名中 reply *Response 是强制要求，RPC 框架需通过指针修改其内容。
- 错误处理不可省略：虽然本例返回 nil，但在真实场景中，务必检查输入合法性并返回有意义的错误（如 errors.New("invalid args")），否则 error: null 可能掩盖逻辑缺陷。
- 对比验证：若临时将 *Response 改为 *string 能工作，正是上述导出问题的典型信号——因为内置类型 string 本身可导出，无需字段级控制。
✅ 总结
Gorilla JSON-RPC 返回空 result 几乎总是结构体字段未导出所致。牢记 Go 的黄金法则：“首字母大写 = 可导出 = 可被 JSON 编码”。修正字段命名后，无需改动任何逻辑、路由或客户端，即可立即获得完整、符合 JSON-RPC 规范的响应。这是 Go 静态类型与反射机制协同下的必然行为，理解它，就能避开 90% 的 RPC 序列化疑难。
