C#怎么使用gRPC双向流_C#如何实现高效RPC调用【进阶】

gRPC双向流不卡死的关键是并发驱动双流而非串行等待，服务端需在同CallContext下并行收发，客户端避免提前CompleteAsync，并捕获OperationCanceledException；连接复用、HTTP/2明文支持及Kestrel配置也至关重要。gRPC 双向流在 C# 里怎么写才不卡死双向流（Bidirectional streaming）本质是客户端和服务端各自维持一个独立的 IAsyncEnumerable<t></t> 流，但很多人一上来就用 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<T> 在双向流里比 Task<T> 更吃 CPU不是语法问题，是底层帧调度机制导致的：每个 yield return 都会触发一次 HTTP/2 DATA 帧封装 + 序列化，而 Task<T> 是单次完整序列化。高频小消息场景下，序列化+帧头开销远超业务数据本身。 灵办AI 免费一键快速抠图，支持下载高清图片