gRPC服务端流Context触发Done（context canceled）的场景排查

以下是几种会导致server.Context().Done()触发且日志输出"context canceled"的常见情况，已排除客户端主动取消的场景：

• 服务端内部的超时/主动取消逻辑
  若服务端代码中使用了context.WithTimeout或context.WithDeadline创建了关联的Context，当超时时间到达时，该Context会被自动取消，触发Done()通道并输出"context canceled"。另外，如果服务端其他goroutine调用了该Context对应的cancel()函数，也会直接触发这个结果。

• 底层TCP连接异常
  当客户端与服务端之间的TCP连接因网络波动、客户端进程意外崩溃、防火墙强制断开等原因中断时，gRPC底层会检测到连接失效，进而自动取消服务端流的Context，此时会输出"context canceled"。这种场景下客户端没有主动调用取消逻辑，但连接已不可用。

• gRPC流的空闲/流量控制触发
  如果客户端长时间未接收流数据（比如客户端处理逻辑阻塞、消费速度过慢），gRPC的流量控制机制可能会触发Context取消；此外，若服务端配置了grpc.KeepaliveParams等空闲超时参数，当流长时间无交互时，服务端会主动终止流并取消Context。

• 服务端进程的外部信号或资源问题
  服务端进程收到终止信号（如SIGINT、SIGTERM），或者因系统资源耗尽（内存不足、CPU超限被系统限制），可能会导致当前流的Context被取消，输出"context canceled"。

• gRPC框架内部错误处理
  当gRPC框架在处理流数据时遇到内部错误（比如消息序列化/反序列化失败、流状态异常），会主动取消Context以终止异常流，此时也会出现该日志。

排查建议 #

• 梳理服务端代码中所有关联该流Context的超时、取消逻辑，确认是否存在未预期的触发点。
• 监控服务端与客户端之间的网络链路，排查是否存在频繁断连、丢包等异常。
• 检查gRPC服务端的配置参数，重点关注Keepalive、流超时相关的设置。
• 查看服务端进程的系统日志，确认是否有信号、资源告警等记录。

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