GRPC服务端同步流：写入失败处理与流关闭方法调用疑问

1. Write返回false时的处理方式 #

当writer->Write(reply)返回false，说明当前流已经无法继续写入（比如客户端主动断开、网络中断、流被框架标记为失效），这时候必须显式关闭流，不能只返回错误状态：

• 先调用writer->WritesDone()：告诉客户端服务端不会再发送任何消息，这是流式调用正常结束前的必要信号；
• 再调用writer->Finish(grpc_status_code)：传入对应的错误状态码（比如GRPC_STATUS_UNAVAILABLE表示网络不可用），正式结束整个流式调用，释放服务端的流资源。
  只返回错误状态而不关闭流，会导致服务端的流资源无法及时释放，长期运行可能引发内存泄漏，同时客户端可能会一直处于等待状态，无法正确感知调用结束。

2. 网络异常仅返回错误不关闭流，恢复后的流状态 #

网络异常导致写入失败后，即使后续网络恢复，这个已经失效的旧流也无法复用。因为gRPC的流式调用基于HTTP/2的流机制，一旦底层网络断开，对应的HTTP/2流会被终止，框架不会自动重建这个流。客户端会收到错误提示，需要重新发起新的流式调用才能继续通信。

3. 未调用WritesDone和Finish却正常运行的原因 #

你遇到的这种情况，是因为部分gRPC框架实现会在特定场景下隐式清理流资源：比如服务端的流式方法执行完毕返回后，框架会自动调用Finish；或者客户端主动断开连接后，框架会触发服务端流的清理。但这种隐式行为并不稳定，不同语言、不同版本的gRPC实现可能有差异，在高并发或复杂网络场景下，很容易出现资源泄漏问题。所以不要依赖这种隐式处理，必须按照规范显式调用WritesDone()和Finish()来结束流。

内容的提问来源于stack exchange，提问作者Chuanlong Song