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