gRPC超时错误源于客户端context超时早于服务端响应，主因是超时设置过短、服务端阻塞未响应ctx.Done()、网络链路延迟叠加或context复用/未清理。

这是因为客户端设置的超时时间太短，而服务端还没来得及返回响应，上下文就已过期并被取消。

客户端超时时间设得太小

gRPC调用依赖 context.Context 控制生命周期。如果用 context.WithTimeout 或 context.WithDeadline 设置了过短的时间（比如 100ms），而服务端实际处理要 300ms，那还没等结果回来，上下文就触发 Done()，gRPC 自动中止请求，报出 DeadlineExceeded 错误。

• 常见写法：ctx, cancel := context.WithTimeout(context.Background(), 100*time.Millisecond)
• 错误本质：不是网络断了，也不是服务挂了，是“等不及了”
• 默认行为：不显式设超时，gRPC 不会自动加限制（可能无限等待）

服务端处理耗时超出预期

即使客户端设了合理超时，服务端若存在阻塞逻辑，也会导致超时。比如：

• 同步执行慢 SQL 查询，没传 ctx 给数据库驱动
• 读大文件、调外部 HTTP 接口未设超时、死循环或锁竞争
• 协程卡在某个 channel 等待，没监听 ctx.Done()

注意：服务端收到超时信号后，不会立刻停止执行，只是把 ServerCallContext.CancellationToken（Go 中是 ctx.Done()）置为可读，需业务代码主动检查并退出。

连接层或中间链路延迟叠加

超时是端到端的总耗时，包括：

• DNS 解析、TCP 建连、TLS 握手
• 请求序列化 + 网络传输（跨机房、高丢包率）
• 服务发现、负载均衡、网关转发（如 Envoy、Nginx）
• 上游服务再调下游，deadline 被逐级继承压缩

例如客户端设 500ms 超时，光建连+序列化就用了 300ms，留给业务逻辑只剩 200ms —— 很容易踩线。

没正确释放 cancel 函数或复用错误 context

每次调用都应新建带超时的 context，并在结束后调 cancel()：

• 漏掉 defer cancel() → goroutine 泄漏，资源积压
• 把一个 context 重复用于多个 RPC → 第一次超时后，后续调用直接失败
• 在长连接池里复用带 deadline 的 context → 后续请求沿用已过期的 deadline

正确做法：每个 RPC 调用前生成新 context，用完即 cancel。

基本上就这些。核心就一条：超时不是异常，是主动控制；问题不在报错本身，而在超时值和实际耗时是否匹配、上下文是否被正确定义和清理。