gin 不适合做纯 rpc 网关，因其本质是 http 路由框架，无内置 grpc/thrift 等二进制协议解析能力，直接转发会因 content-type 和帧头校验失败而报错。
为什么 Gin 不适合做纯 RPC 网关
直接说结论：Gin 本质是 HTTP 路由框架，没有内置对 gRPC、Thrift 或其他二进制 RPC 协议的解析能力。如果你试图用 Gin 直接转发 gRPC 请求（比如 POST 到 /rpc），会卡在 Content-Type: application/grpc 和帧头（0x00 + 4-byte length）上——Gin 默认的 BindJSON 或 Bind 会直接报错 invalid character '' looking for beginning of value。
真正能跑通的路径只有一条：把 Gin 当成「HTTP 入口层」，后端用原生 grpc-go 或 net/rpc 处理协议；Gin 负责鉴权、限流、日志、HTTP-to-RPC 映射等胶水逻辑。
如何用 Gin 做 HTTP-to-gRPC 透传网关
核心思路是绕过 Gin 的 body 解析，用 c.Request.Body 原始字节流交给 gRPC 客户端。注意：必须禁用 Gin 的自动 body 读取，否则 io.EOF 会导致后续 grpc.ClientConn 读不到数据。
- 在路由注册前加
gin.SetMode(gin.ReleaseMode)，避免开发模式下额外中间件干扰 - 用
c.Request.Header.Get("Content-Type")判断是否为application/grpc，不是就走普通 HTTP 逻辑 - 调用
io.ReadAll(c.Request.Body)获取原始 payload，再用grpc.NewClient的Invoke方法发请求（不是UnaryClientInterceptor） - 响应要手动设置
c.Data(200, "application/grpc", data)，不能用c.JSON
示例关键片段：
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
func grpcProxy(c *gin.Context) {
// 阻止 Gin 自动读 body
c.Request.Body = io.NopCloser(c.Request.Body)
body, _ := io.ReadAll(c.Request.Body)
conn, _ := grpc.Dial("127.0.0.1:50051", grpc.WithTransportCredentials(insecure.NewCredentials()))
defer conn.Close()
// 手动构造 grpc.Invoke 调用
resp, err := grpc.Invoke(context.Background(), c.Request.URL.Path, body, &respBody, conn, grpc.EmptyCallOption{})
if err != nil {
c.AbortWithStatus(502)
return
}
c.Data(200, "application/grpc", resp.([]byte))
}
Gin 中处理 JSON-RPC 2.0 的坑
如果后端是 JSON-RPC（如 gorilla/rpc 或自研服务），Gin 可以直接处理，但要注意三个硬伤：
-
BindJSON会强制要求Content-Type: application/json，而很多 JSON-RPC 客户端发的是text/plain—— 必须手动用io.ReadAll(c.Request.Body)读，再json.Unmarshal - JSON-RPC 的
id字段可能是string或number，Go struct 定义要用json.RawMessage或interface{}，否则反序列化失败 - 错误响应格式必须严格匹配 JSON-RPC 2.0 规范（
error字段含code/message），不能用c.Error()，得手写c.JSON(200, map[string]interface{}{"jsonrpc":"2.0", "error":...})
性能与连接复用的关键点
Gin 本身轻量，但网关性能瓶颈几乎全在 RPC 连接层。别在每次请求里新建 grpc.ClientConn 或 http.Client，否则会迅速耗尽文件描述符。
- gRPC 场景：全局复用一个
*grpc.ClientConn，用grpc.WithBlock()+grpc.WithTimeout控制建连行为 - HTTP RPC 场景：用
&http.Client{Transport: &http.Transport{MaxIdleConns: 100}}，避免默认的2连接上限 - 务必给所有 RPC 调用加 context 超时：
ctx, cancel := context.WithTimeout(c.Request.Context(), 3*time.Second)，不然慢请求会拖垮整个网关
最易被忽略的是 gRPC 的 KeepAlive 参数——内网网关若不设 grpc.WithKeepaliveParams，长连接可能被中间设备静默断开，导致偶发 transport is closing 错误。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
