grpc server 默认无连接数限制，实际受限于操作系统和go运行时；需通过keepaliveparams管理连接生命周期，并用拦截器+令牌桶限流控制并发请求。
gRPC Server 默认没有硬性连接数限制
Go 语言的 grpc.Server 本身不设连接数上限，底层依赖 net/http2.Server，而后者把连接管理交给了 Go 标准库的 net.Listener（比如 net.TCPListener）。真正起作用的是操作系统级限制和 Go runtime 的资源约束。
常见误判是看到大量连接堆积后怀疑 gRPC 框架“卡住了”，其实往往是服务端处理慢、客户端重试激增、或 TCP 层未及时回收 TIME_WAIT 连接导致端口耗尽。
- linux 默认
net.core.somaxconn通常为 128，影响listen()队列长度，超限连接会被内核丢弃（客户端报connection refused） - Go 的
net.Listen默认使用tcpKeepAliveListener，但 keepalive 参数需显式设置，否则空闲连接可能长期滞留 -
grpc.Server启动时若未配置KeepaliveParams，长连接不会被主动探测或断开，容易积累无效连接
如何用 KeepaliveParams 控制连接生命周期
gRPC 内置的保活机制不是用来限流的，但能间接减少僵尸连接。关键参数必须成对理解：服务端发送 ping 的频率，和客户端响应超时时间之间存在依赖关系。
典型错误是只设 MaxConnectionAge 却忽略 MaxConnectionAgeGrace，导致连接在关闭瞬间仍有请求正在处理，引发 UNAVAILABLE 错误。
-
ServerParameters.MaxConnectionAge：连接最大存活时间（如 30 * time.Minute），到期后服务端发 GOAWAY -
ServerParameters.MaxConnectionAgeGrace：GOAWAY 后允许请求完成的宽限期（如 5 * time.Second），必须 > 0，否则立即断连 -
EnforcementPolicy.MinTime：客户端两次 ping 的最小间隔，设太小会增加无谓流量；设太大则无法及时发现断连 - 注意：
KeepaliveParams只影响 HTTP/2 连接层，不控制业务请求并发数
真正限制并发请求得靠拦截器 + 限流器
连接数 ≠ 并发请求数。一个 gRPC 连接可复用承载成百上千个 stream 或 unary 请求。要防雪崩，必须在业务入口做请求级限流，而不是等连接堆满才反应。
直接在 grpc.Server 启动时传入 UnaryInterceptor 是最轻量的做法。别用全局锁或 channel 阻塞，性能差且难以观测。
- 推荐用
golang.org/x/time/rate.Limiter做令牌桶限流，每秒允许 N 次请求，超限返回status.Errorf(codes.ResourceExhausted, "...") - 避免按方法名硬编码限流阈值，应从配置中心加载，或用
method字符串做 key 实现差异化限流（如/api.UserService/GetUser和/api.UserService/BatchGet分开控） - 不要在拦截器里做耗时操作（如查 redis），否则限流器本身变成瓶颈；预热阶段可提前初始化
rate.Limiter实例
排队策略不能只靠缓冲区，得配合客户端行为
gRPC 没有内置“请求队列”概念。所谓排队，其实是客户端在连接池满、或收到 UNAVAILABLE 后自行重试造成的表象。服务端唯一能做的，是让失败反馈更明确、更及时。
常见陷阱是开启 MaxConcurrentStreams（HTTP/2 设置），以为能限流，结果只是让新 stream 被拒绝，客户端看不到原因，反复重试加重压力。
-
MaxConcurrentStreams是 per-connection 限制，默认 100，调低会导致单连接吞吐骤降，不解决整体负载问题 - 更有效的是在拦截器中判断当前 goroutine 数（如用
runtime.NumGoroutine()粗略估算），超阈值时快速返回codes.Unavailable，引导客户端退避 - 务必让客户端启用
WithBlock()+WithTimeout()，避免阻塞在连接建立上；服务端也应设置合理的ReadBufferSize/WriteBufferSize，防止大 payload 占满缓冲区
真正难的不是配几个参数，而是区分清楚：哪些问题属于连接管理，哪些属于请求调度，哪些其实是下游依赖拖慢了响应。混在一起调，永远只能治标。