grpc-go 设小流窗口后吞吐下降：连接窗口也会变成静态

给 grpc-go 配上 WithStaticStreamWindowSize 后，单流窗口似乎受控了，大消息传输却明显变慢。先检查连接级窗口：这项设置会关闭动态流控，并不只固定单个流而让连接继续按带宽时延积自动增长。

一种具体场景是把流窗口设为 1 MiB，用于减缓写入较慢存储的响应；连接窗口却仍停留在较小值。后续大消息需要更频繁地等待窗口更新，吞吐可能受到影响。它与消息本身的 2 MiB 大小、应用读取节奏和网络时延共同有关，不能把某个窗口值当成所有部署的性能答案。

优先评估是否需要静态窗口

在 grpc-go 1.81.0 与 1.84.0 的实现中，静态流窗口和静态连接窗口选项都会设置同一个静态流控标记。没有特别要求时，保留动态估算通常比手工固定更合适。

如果只是某个 RPC 下游写盘较慢，优先在该业务路径安排有界缓冲与消费速度控制。客户端拨号选项影响整条连接上的调用，可能连带限制本来可以快速消费的其他 RPC。流控窗口也不是“最多缓存一条消息”的应用队列承诺，消息分帧、解码和应用层缓冲都需要考虑。

必须静态时同时规划两个窗口

确有静态窗口需求，可在既有客户端拨号选项中同时指定两级窗口，例如：

opts := []grpc.DialOption{
    grpc.WithStaticStreamWindowSize(1 << 20),
    grpc.WithStaticConnWindowSize(4 << 20),
}

这是使用 google.golang.org/grpc 的局部配置示例，1 MiB 与 4 MiB 只是便于说明的数值，不是推荐基准。应与原连接参数合并，保留认证、超时与拦截器。较大的连接窗口可能增加在途数据和内存压力，需要按并发流数量与实际预算决定。

如果撤掉静态流选项，检查是否还留下其他会关闭动态流控的静态选项；只改其中一处，不一定恢复自动估算。服务端配置有自己的对应入口，客户端调整也不会替你重设对端。

验收覆盖慢消费 RPC、快速 RPC、并发流和取消场景，比较原窗口、默认动态流控与审定静态组合下的吞吐和内存。确认其他调用没有被共同限速，且应用缓冲仍受控；仅看到一条大消息完成，无法证明背压和资源预算都正确。