gRPC在Go中需精细配置才能发挥高性能：必须使用proto3语法、禁用JSON映射、复用ClientConn并设置Keepalive参数，避免默认配置导致性能下降。

gRPC 在 Go 中默认就是高性能的，但“高性能”不等于“开箱即用无脑快”——它高度依赖协议设计、序列化选择、连接复用和流控配置。盲目套用默认 grpc.Dial 或未关闭 ClientConn 反而会拖垮吞吐量。

定义 .proto 时必须显式启用 proto3 并禁用 JSON 映射

Go 的 protoc-gen-go 默认生成兼容性优先的代码，但若启用了 json_name 或保留 optional 字段语义（proto2 风格），会引入反射和额外内存分配。高性能场景下应严格使用 proto3 语义，并在 .proto 文件顶部声明：

syntax = "proto3";
option go_package = "example.com/pb";
option java_package = "com.example.pb";
// 禁用 JSON 映射（避免 runtime/jsonpb 兼容层）
option php_class_prefix = "PB";

生成命令也需明确指定：

protoc --go_out=paths=source_relative:. \
       --go-grpc_out=paths=source_relative:. \
       service.proto

• 不加 --go_opt=paths=source_relative 会导致导入路径错误，引发编译失败
• 避免使用 protoc-gen-go-grpc 旧版插件（v1.1+ 已弃用），改用官方维护的 google.golang.org/grpc/cmd/protoc-gen-go-grpc

客户端必须复用 ClientConn 并设置合理的 Keepalive 参数

每次调用都新建 grpc.Dial 会触发完整 TCP 握手 + TLS 协商，延迟飙升且耗尽文件描述符。真实服务中应全局复用单个 *grpc.ClientConn。

立即学习“go语言免费学习笔记（深入）”；

关键配置项：

• grpc.WithTransportCredentials(credentials.NewTLS(...))：生产环境必须启用 TLS，禁用 grpc.WithInsecure()
• grpc.WithKeepaliveParams(keepalive.ClientParameters{Time: 30 * time.Second})：防止中间设备（如 Nginx、AWS NLB）因空闲超时断连
• grpc.WithDefaultCallOptions(grpc.MaxCallRecvMsgSize(16 * 1024 * 1024))：避免大消息被截断，默认仅 4MB

示例初始化：

conn, err := grpc.Dial("api.example.com:443",
    grpc.WithTransportCredentials(credentials.NewTLS(&tls.Config{})),
    grpc.WithKeepaliveParams(keepalive.ClientParameters{
        Time:                30 * time.Second,
        Timeout:             10 * time.Second,
        PermitWithoutStream: true,
    }),
    grpc.WithDefaultCallOptions(
        grpc.MaxCallRecvMsgSize(16 << 20),
        grpc.MaxCallSendMsgSize(16 << 20),
    ),
)
if err != nil {
    log.Fatal(err)
}
defer conn.Close() // 注意：只在应用退出时 Close，不是每次请求后

服务端需启用流控和并发限制，避免 goroutine 泛滥

gRPC 默认不限制并发请求数，一个恶意客户端持续发小包即可耗尽服务器 goroutine（每个 RPC 调用至少启动 1 个新 goroutine）。必须通过拦截器或底层 listener 控制连接与请求速率。

• 使用 grpc.Server 的 MaxConcurrentStreams 选项限制每连接最大并发流数（默认 100，建议设为 50–200）
• 配合 runtime.ServerMetadata 或自定义拦截器做 per-method 限流（如用 golang.org/x/time/rate）
• 禁用反射服务：grpc.EnableTracing(false) 和移除 reflection.Register()，减少内存占用和攻击面

启动时关键配置：

srv := grpc.NewServer(
    grpc.MaxConcurrentStreams(100),
    grpc.StatsHandler(&customStatsHandler{}), // 可选：监控 QPS/延迟
    grpc.ChainUnaryInterceptor(authInterceptor, rateLimitInterceptor),
)
pb.RegisterUserServiceServer(srv, &userServer{})

性能瓶颈往往不在 gRPC 层，而在序列化与业务逻辑阻塞

实测表明：当业务 handler 中包含数据库查询、HTTP 调用或复杂计算时，gRPC 本身的开销占比通常低于 5%。真正卡点是同步阻塞操作。

• 避免在 unary handler 中直接调用 http.DefaultClient.Do 或 db.QueryRow —— 改用带上下文取消的异步版本
• Proto message 字段尽量用 sint32/sint64 替代 int32/int64，减少 ZigZag 编码开销（对频繁更新的计数字段有效）
• 不要在 proto 中定义嵌套过深的结构（>5 层），Go 的 protobuf 反序列化会显著变慢

一个典型低效写法：

// ❌ 错误：阻塞式 DB 查询
func (*server) GetUser(ctx context.Context, req *pb.GetUserRequest) (*pb.User, error) {
    row := db.QueryRow("SELECT name FROM users WHERE id = $1", req.Id)
    var name string
    row.Scan(&name) // 同步阻塞，无法响应 ctx.Done()
    return &pb.User{Name: name}, nil
}

应改为：

// ✅ 正确：支持 cancel 的查询
func (*server) GetUser(ctx context.Context, req *pb.GetUserRequest) (*pb.User, error) {
    row := db.QueryRowContext(ctx, "SELECT name FROM users WHERE id = $1", req.Id)
    var name string
    if err := row.Scan(&name); err != nil {
        return nil, status.Error(codes.NotFound, "user not found")
    }
    return &pb.User{Name: name}, nil
}

最常被忽略的一点：gRPC 的“高性能”建立在长连接、二进制协议和零拷贝序列化基础上，一旦你在中间加一层 HTTP/1.1 代理（比如用 Nginx 做 TLS 终结但没配 http2），整个链路就退化成 HTTP/1.1 + base64 编码，吞吐直接腰斩。确认链路是否真走 HTTP/2 的唯一方式是抓包看 ALPN 协议协商结果。