grpc流控是http/2强制机制，initialwindowsize和initialconnwindowsize不可盲目调大，否则引发内存暴涨或oom；maxconcurrentstreams应设为100防过载；流控失效表现为无错误但延迟飙升、rcv_space趋零、消息积压。
gRPC 的流控不是可选功能，而是 HTTP/2 协议强制启用的底层机制；它不靠你写代码实现，但一旦配置不当，服务会在高并发下出现吞吐骤降、连接卡死、内存暴涨等“安静崩溃”现象。
为什么 InitialWindowSize 和 InitialConnWindowSize 不能随便调大
这两个参数控制接收方能缓存多少未处理数据（单位字节），看似“越大越快”，实则极易引发资源错配：
-
InitialWindowSize是每个 stream 的窗口，默认65535（64KB）。设为10MB后，单个长连接若有 100 个并发 stream，仅窗口缓冲就吃掉 1GB 内存 -
InitialConnWindowSize是整条连接的总窗口，默认也是65535。若设得过大（如100MB），服务端可能一次性接收远超业务处理能力的数据，触发 GC 频繁或 OOM - HTTP/2 要求接收方主动发
WINDOW_UPDATE帧来“充值”窗口，若业务逻辑阻塞（比如 DB 查询慢），窗口无法及时恢复，后续 DATA 帧会被对端暂停发送——表现为请求“挂住”，但无错误日志
建议：从默认值起步；若需提升突发吞吐，优先调大 InitialConnWindowSize（如 8MB），InitialWindowSize 保持 1MB 以内；上线后紧盯 grpc_server_handled_total 和 Go runtime 的 memstats.Alloc。
MaxConcurrentStreams 是防过载的第一道闸门
它限制单个 TCP 连接上最多并行多少个 stream，和流控协同工作——窗口管“数据量”，这个参数管“请求数”：
- 默认不限制（Go gRPC 实现中为
math.MaxUint32），意味着一个连接可承载成百上千 stream，极易压垮单个 goroutine 处理器或数据库连接池 - 设为
100后，客户端超出的请求会立刻收到RESOURCE_EXHAUSTED错误，而非排队等待，避免雪崩式延迟累积 - 注意：该参数只作用于服务端
ServerOption，客户端拨号时无法设置；且它不区分 unary 或 streaming，所有 stream 统一计数
示例配置：
server := grpc.NewServer(<br> grpc.MaxConcurrentStreams(100),<br>)
流控失效的典型信号：没有报错，但延迟飙升
当看到以下现象，大概率是流控参数与业务节奏不匹配，而非网络或 CPU 瓶颈：
- 客户端
grpc.ClientConn日志中频繁出现transport: loopyWriter.run returning. connection error，但服务端无 panic - 服务端
grpc.Server指标中grpc_server_stream_msgs_received_total增速远高于grpc_server_handled_total，说明大量消息卡在接收缓冲区没被读走 - 用
ss -i查看连接，发现rcv_space长期接近 0，而retrans字段缓慢增长——这是对端因窗口耗尽停止发包的 TCP 层证据
此时别急着加机器，先检查 handler 是否阻塞在同步 IO（如未 context.Done() 检查的 time.Sleep）、是否漏调 Recv() 或 Send() 导致流无法推进。
流控参数调优不是一次配置到位的事，它必须和你的 handler 执行时间分布、消息平均体积、连接复用策略一起看；最容易被忽略的是：窗口大小不是“越大越好”，而是“刚好够撑过最慢 handler 的执行间隙”。
