选gRPC还是JSON-RPC取决于场景：gRPC适合内部高一致性、高吞吐的Go微服务链路；JSON-RPC或net/rpc更轻量，适合跨语言调试或Go运维工具。
用 gRPC 还是 JSON-RPC？选型直接决定调试成本
Go 微服务间 RPC 通信，gRPC 是默认首选，但不是所有场景都适合。如果你的服务要被 Python/JS 客户端频繁调用、需要浏览器直连、或团队对 Protocol Buffers 不熟，JSON-RPC（配合 net/rpc 或 gorilla/rpc）反而更轻量、易 debug。
常见错误：用 gRPC 对接前端 fetch 请求，结果卡在 CORS 或 HTTP/2 不兼容上；或者用 net/rpc 暴露服务却忘了它默认只支持 Go 客户端，其他语言根本连不上。
-
gRPC要求定义.proto文件，生成强类型 stub，适合内部高一致性、高吞吐服务（如订单→库存→支付链路） -
net/rpc基于 Go 的encoding/gob，仅限 Go-to-Go，启动快、无依赖，适合运维工具类微服务间短时通信 - 若需跨语言且拒绝 protobuf，可选
JSON-RPC 2.0+gorilla/rpc，但注意它不自带服务发现和重试
gRPC Server 启动时 panic: "transport: http2Server.HandleStreams received bogus greeting"
这个错误基本等于客户端没按 HTTP/2 + TLS（或明文 h2c）规范发起连接。Go 的 grpc.Server 默认要求 TLS，但开发环境常想跳过证书——必须显式启用 h2c（HTTP/2 without TLS）。
正确做法不是关 TLS，而是用 grpc.Creds 配合 credentials.NewTLS(nil) 不够，得换底层 listener：
立即学习“go语言免费学习笔记（深入）”；
lis, _ := net.Listen("tcp", ":8080")
// 关键：用 http2.ConfigureServer 包一层
s := &http2.Server{}
grpcServer := grpc.NewServer(
grpc.ForceServerCodec(&codec{}), // 可选：自定义编解码
)
httpServer := &http.Server{
Addr: ":8080",
Handler: h2c.NewHandler(grpcServer, &s),
}
httpServer.Serve(lis) // 而非 grpcServer.Serve(lis)
否则 curl 或 Postman 直连会报上述错误；用 grpcurl 则必须加 -plaintext 参数。
net/rpc 注册方法名必须首字母大写且带接收者
net/rpc 对方法签名极其敏感：必须是导出方法（首字母大写），且第一个参数为指针或值类型，第二个必须是指针类型响应。漏掉任一条件，rpc.Register 不报错，但客户端调用返回 "method not found"。
HISUI 前端框架基础开发指南。HISUI 是基于 easyui 二次开发的 jQuery UI 组件库，专为医疗信息系统设计。当涉及 HISUI 组件开发、jQuery easyui 表格/表单/布局/窗口、医疗系统前端页面编写时使用此 skill。 涵盖 40 个组件的官方文档参考，支持声明式与编程式两种初始化方式，提供 $cm/$m 数据访问方法。
典型错误写法：
func (s *Service) processOrder(req OrderRequest, resp *OrderResponse) error { ... } // 小写 processOrder → 不可见
func (s *Service) ProcessOrder(req OrderRequest, resp OrderResponse) error { ... } // resp 不是指针 → 拒绝注册
正确写法：
func (s *Service) ProcessOrder(req *OrderRequest, resp *OrderResponse) error {
*resp = OrderResponse{ID: req.ID + "-done"}
return nil
}
另外，net/rpc 默认用 gob 编码，不兼容其他语言；若强行传 JSON 字符串，需自定义 Codec，但代价是失去标准反射机制。
超时控制不能只靠 context.WithTimeout —— 底层连接也得设
RPC 调用中只在 client 端用 ctx, cancel := context.WithTimeout(ctx, 5*time.Second) 是不够的。gRPC 的底层 HTTP/2 连接可能因网络卡顿迟迟不建立，而 context 超时只作用于 RPC 方法调用阶段，不覆盖 dial 阶段。
必须显式配置 grpc.WithTimeout（已弃用）或更可靠的 grpc.WithTransportCredentials + 自定义 grpc.DialOption：
conn, err := grpc.Dial("127.0.0.1:8080",
grpc.WithTransportCredentials(insecure.NewCredentials()),
grpc.WithBlock(), // 同步阻塞等待连接成功
grpc.WithTimeout(3*time.Second), // 连接级超时（注意：gRPC v1.60+ 已移除此选项）
)
// 替代方案：用 grpc.WithDialer + net.DialTimeout
实际项目中建议统一封装 dial 函数，把连接超时、keepalive、backoff 都固化进去，避免每个服务单独写重复逻辑。
真正难处理的是 streaming 场景：context 超时后，server 端 goroutine 可能还在跑，必须靠业务层主动检查 ctx.Done() 并提前 return，否则资源泄漏比 REST 更隐蔽。
