gRPC双向流不卡死的关键是并发驱动双流而非串行等待，服务端需在同CallContext下并行收发，客户端避免提前CompleteAsync，并捕获OperationCanceledException；连接复用、HTTP/2明文支持及Kestrel配置也至关重要。
gRPC 双向流在 C# 里怎么写才不卡死
双向流（Bidirectional streaming）本质是客户端和服务端各自维持一个独立的 IAsyncEnumerable 流，但很多人一上来就用 await foreach 同时读写，结果服务端还没发完、客户端就提前退出了——根本不是性能问题，是流生命周期没对齐。
关键点在于：两个流必须并发驱动，不能串行等待。常见错误是写成「先收完所有请求再发响应」，这直接破坏了流式语义。
- 服务端必须用
async Task方法体，且在同一个CallContext下同时启动接收和发送逻辑 - 客户端调用
RequestStream.WriteAsync()后，别立刻await RequestStream.CompleteAsync()，除非你真想关流 - 务必处理
OperationCanceledException：网络抖动或对方断连时，WriteAsync或ReadAsync可能抛这个，不捕获会导致整个 call 崩溃
await foreach (var req in requestStream.ReadAllAsync(ct))
{
// 处理请求，但别在这里 await 响应发送
responseStream.WriteAsync(new Response { ... }, ct);
}
await responseStream.CompleteAsync(ct); // 这句放最后，且仅当你要主动结束响应流
C# gRPC 客户端怎么避免 RpcException: Status(StatusCode=Unavailable, Detail="Connection reset")
这不是服务挂了，大概率是客户端没配好连接复用或超时策略。gRPC over HTTP/2 对底层 TCP 连接更敏感，短连接模式下频繁重建会触发重置。
重点看三个地方：
-
GrpcChannel必须复用，别每次调用都GrpcChannel.ForAddress(...)—— 创建开销大，且默认不共享连接池 - 在
AppContext.SetSwitch("System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport", true)这种非 TLS 场景下，必须显式开启 HTTP/2 明文支持（否则降级到 HTTP/1.1，双向流直接失败） - 服务端
Kestrel配置里如果设了HttpProtocols = HttpProtocols.Http1AndHttp2，但没配AllowSynchronousIO = false，也会在高并发时触发连接中断
为什么 IAsyncEnumerable 在双向流里比 Task 更吃 CPU
不是语法问题，是底层帧调度机制导致的：每个 yield return 都会触发一次 HTTP/2 DATA 帧封装 + 序列化，而 Task 是单次完整序列化。高频小消息场景下，序列化+帧头开销远超业务数据本身。
适用边界很明确：
- 消息体平均 > 1KB，且发送频率 IAsyncEnumerable 没压力
- 消息体 Task
打包聚合，或换 ServerStreaming+ 缓冲区攒批 - .NET 6+ 可以用
JsonSerializerOptions.DefaultBufferSize = 8192降低序列化分配，但治标不治本
从 .NET 5 升到 .NET 7 后双向流吞吐掉了一半？
不是 runtime 退化，是 Grpc.Net.Client 4.x 默认启用了 EnableDetailedErrors（开发期友好，生产期伤性能）。它会让每个响应帧额外附带调试元数据，增加约 15% 的序列化耗时和带宽占用。
上线前必须关掉：
- 服务端
AddGrpc().AddServiceOptions(o => o.EnableDetailedErrors = false) - 客户端
GrpcChannelOptions构造时传入new GrpcChannelOptions { ThrowOnRpcFailure = false }，避免异常路径被反复捕获包装 - 检查是否误开了
Environment.SetEnvironmentVariable("GRPC_VERBOSITY", "DEBUG")—— 这个环境变量会让所有日志变成同步 IO，压测时尤其致命
真正难调的是流控窗口和 MaxStreamsPerConnection 的组合影响，这两个值一旦配错，表现就是吞吐忽高忽低，查起来要抓 HTTP/2 SETTINGS 帧，不是改代码能解决的。
