context.withtimeout是go微服务中超时控制的唯一可靠方式，它通过传播取消信号中断阻塞操作，而time.sleep无法替代；grpc需显式配置withblock与withtimeout避免连接未就绪错误；http transport须调优maxidleconns等参数提升复用率；sync.pool仅对固定大小字节缓冲有效。
为什么 context.WithTimeout 比裸写 time.Sleep 更关键
微服务调用链里，延迟不是来自单次 RPC 耗时，而是阻塞等待的累积。用 time.Sleep 模拟重试或降级，会掩盖真实超时点，导致下游持续堆积请求。
-
context.WithTimeout是 Go 原生传播取消信号的唯一可靠方式，所有标准库 client（如http.Client、grpc.Dial）都依赖它触发中断 - 不传
context或传context.Background()等同于放弃超时控制，哪怕你设置了http.Client.Timeout，底层连接池仍可能卡在 DNS 解析或 TLS 握手阶段 - 常见错误：在中间件里用
time.AfterFunc手动 cancel context —— 这无法穿透到 net/http 的底层连接，实际无效
正确姿势是：每次发起 RPC 前，从上游 context 派生带 timeout 的子 context，并透传到底层调用：
ctx, cancel := context.WithTimeout(r.Context(), 200*time.Millisecond) defer cancel() resp, err := client.Do(ctx, req)
gRPC 客户端连接复用为什么必须显式配置 WithBlock 和 WithTimeout
默认 gRPC client 在首次 grpc.Dial 时不阻塞，会后台异步建连。如果这时立刻发请求，rpc error: code = Unavailable desc = connection closed 就来了——不是网络问题，是连接还没 ready。
- 加
grpc.WithBlock()强制阻塞直到连接就绪，但必须配合grpc.WithTimeout(5 * time.Second)，否则 DNS 失败时会永久 hang 住 - 不设
WithBlock时，必须在每次Invoke前检查conn.GetState() == connectivity.Ready，否则首请求大概率失败 - 连接池大小默认是 1，高并发下容易成为瓶颈；用
grpc.WithDefaultCallOptions(grpc.FailFast(false))避免因单次失败直接 panic，但代价是增加平均延迟
HTTP/JSON RPC 里 http.Transport 的三个致命参数
Go 默认 http.DefaultTransport 对微服务场景极不友好：复用率低、DNS 缓存缺失、keep-alive 超时太短。
立即学习“go语言免费学习笔记（深入）”；
-
MaxIdleConns和MaxIdleConnsPerHost必须设为相同值（如 100），否则跨 host 请求无法复用空闲连接 -
IdleConnTimeout建议设为 30s，太短导致频繁重建 TCP，太长则服务重启后旧连接 linger 造成 503 - 必须设置
ForceAttemptHTTP2: true，否则 HTTP/1.1 下 pipelining 不生效，且无法利用 gRPC-Web 等现代协议 - 忽略
Response.Body.Close()会导致连接永远不归还到 idle pool，最终耗尽MaxIdleConns
为什么 sync.Pool 对 protobuf 序列化没用，但对 JSON 字节缓冲有用
protobuf 反序列化（Unmarshal）内部会分配新 struct 实例，sync.Pool 无法复用；而 JSON 解析常需大块 []byte 缓冲，这里才是池化收益点。
- 别池化
*pb.Request或json.RawMessage，GC 压力反而更大 - 适合池化的对象：固定大小的
bytes.Buffer（预设 cap=4096）、临时[]byte切片（用于io.CopyBuffer） - 注意
sync.Pool不保证对象一定被复用，且 Put 后可能被 GC 清理，所以每次 Get 后必须重置状态（如buf.Reset()）
延迟优化真正卡点往往不在算法，而在连接生命周期管理与 context 信号传递是否干净。一个没被 cancel 的 goroutine，比十次无意义的序列化更拖慢整个调用链。
