gRPC流式传输必须用stream关键字定义方法，单次传大文件需分块（如FileChunk），不可用bytes硬塞；C#客户端须WriteAsync后调CompleteAsync再await ResponseAsync，服务端需流式读写防OOM，并配置HTTP/2流控与超时。
gRPC流式传输必须用 stream 关键字定义服务方法
单次传大文件不能靠 bytes 字段硬塞，Protobuf 有默认 64MB 解析限制，且内存会爆。必须在 .proto 文件里明确定义客户端流、服务端流或双向流。常见错误是写成普通 RPC（如 rpc Upload(FileRequest) returns (UploadResponse)），这根本不是流式。
正确写法示例：
service FileService {
rpc Upload(stream FileChunk) returns (UploadResponse);
rpc Download(FileRequest) returns (stream FileChunk);
}FileChunk 通常包含 bytes data 和可选的 int64 offset、bool is_last 等控制字段。注意：Protobuf 的 bytes 是 base64 编码后传输的，实际二进制体积会膨胀约 33%，对吞吐敏感时得接受这点开销。
C# 客户端上传要用 AsyncClientStreamingCall 写入并等待完成
调用 Upload 这种客户端流方法时，C# gRPC 生成的客户端返回的是 AsyncClientStreamingCall<filechunk uploadresponse></filechunk>，不是直接 await 就完事——你得先 WriteAsync 所有分块，再显式调用 CompleteAsync() 告诉服务端“数据发完了”，最后才能 await ResponseAsync 拿结果。
容易踩的坑：
- 忘记调用
CompleteAsync()→ 服务端永远收不到 EOF，卡死在等待状态 - 在
WriteAsync后立刻await ResponseAsync→ 可能返回空响应或超时，因为服务端还没处理完 - 单次
WriteAsync的FileChunk.data超过 4MB → 触发 gRPC 默认消息大小限制，抛出InvalidOperationException: Status(StatusCode=ResourceExhausted, Detail="...")
建议分块大小设为 1–2MB，并在 Channel 创建时加大限制：
var channel = GrpcChannel.ForAddress("https://localhost:5001",
new GrpcChannelOptions {
MaxReceiveMessageSize = 100 * 1024 * 1024,
MaxSendMessageSize = 100 * 1024 * 1024
});C# 服务端实现流式下载要手动控制 WriteAsync 节奏
服务端处理 Download 方法时，参数是 FileRequest，返回类型是 IServerStreamWriter<filechunk></filechunk>。关键点在于：不能一次性把整个文件读进内存再循环 WriteAsync，而要用 FileStream 分块读 + 异步写，否则大文件照样 OOM。
实操要点：
- 用
FileStream.ReadAsync配合栈上分配的 byte[]（如stackalloc byte[8192]）避免 GC 压力 - 每次
WriteAsync前检查Context.CancellationToken.IsCancellationRequested，支持前端取消下载 - 不要在
WriteAsync后加await Task.Delay控制速率——这会拖慢整体吞吐；真要限速，改用ThrottlingStream包装底层 FileStream
示例核心逻辑片段：
public override async Task Download(FileRequest request, IServerStreamWriter<FileChunk> responseStream, ServerCallContext context)
{
await using var fs = File.OpenRead(request.Path);
var buffer = new byte[1024 * 1024];
int read;
while ((read = await fs.ReadAsync(buffer, context.CancellationToken)) > 0 && !context.CancellationToken.IsCancellationRequested)
{
await responseStream.WriteAsync(new FileChunk { Data = ByteString.CopyFrom(buffer, 0, read) });
}
}HTTP/2 流控和超时配置不调就容易断连
gRPC 底层是 HTTP/2，它的流控窗口默认很小（64KB），如果客户端消费 Download 数据太慢，服务端会因流控阻塞而超时；反过来，上传时若服务端处理 chunk 太慢，客户端也可能被流控压住。这不是代码 bug，而是协议层行为。
必须调整的关键配置：
- 服务端 Kestrel：在
Program.cs中设置Http2.MaxStreamsPerConnection和Http2.KeepAlivePingDelay，避免连接被中间代理（如 Nginx）静默关闭 - 客户端 Channel：通过
ChannelOption设置grpc.http2.max_ping_strikes和grpc.keepalive_time_ms - 所有流式方法都应在
.proto加option (google.api.http) = ...以外的超时注释，而是在 C# 调用侧传CallOptions，例如new CallOptions(deadline: DateTime.UtcNow.AddMinutes(30))
没调这些，传 2GB 文件大概率在 10–15 分钟左右悄无声息断开，错误日志里只有模糊的 StatusCode=Cancelled 或 StatusCode=DeadlineExceeded。
