应优先使用 context.withtimeout 而非 withdeadline，因后者受系统时钟跳变、启动延迟和时间偏差影响；http 客户端需同时设置 client.timeout 和 context 透传；grpc 服务端须主动监听 ctx.done()；超时值须配置化且 cancel 必须 defer。
为什么不能用 time.Now().Add() 配 context.WithDeadline
直接传 time.Now().Add(5 * time.Second) 给 context.WithDeadline 看似等价于 WithTimeout，但会引入三类风险：系统时钟跳变（如 NTP 校正）可能导致 deadline 突然变成过去时间，ctx 立即返回 context.DeadlineExceeded；goroutine 启动延迟导致实际执行窗口被压缩；多个协程各自调用 time.Now() 产生微秒级偏差，破坏统一截止点语义。真正需要绝对时间对齐（比如配合 cron 或外部调度器）才用 WithDeadline，否则一律走 WithTimeout。
http.Client 的 Timeout 和 context 超时必须同时设
http.Client.Timeout 只覆盖整个请求生命周期（DNS + 连接 + TLS + 发送 + 读响应头），但不包含响应体流式读取——大文件下载或 gRPC 流式响应可能卡在 resp.Body.Read() 阶段，此时仅靠 client timeout 无效。必须把 context 透传进 request：req.WithContext(ctx)，否则底层连接不会响应 cancel 信号。常见错误是只设了 client timeout，却忘了在 Do() 前绑定 ctx。
-
Transport层建议额外配DialTimeout（连接建立）、TLSHandshakeTimeout（TLS 握手）、ResponseHeaderTimeout（等待响应头） - 若用 resty、gorest 等封装库，检查其
SetContext()是否真正透传到原始*http.Request - Kubernetes 中
Service.externalTrafficPolicy: Local可能导致连接 hang 住，此时只有 context 超时能强制退出
gRPC 客户端传 ctx 不等于服务端自动中断
客户端调用时传入带超时的 ctx，只是把 deadline 编码进 metadata 发给服务端；服务端必须显式监听 ctx.Done() 并主动 return，否则业务逻辑仍会继续执行。典型漏点是：在 handler 里开了 goroutine 处理耗时任务，但没把 ctx 传进去，或没在循环中检查 ctx.Err() == context.Canceled。
- 服务端应在关键路径（如数据库查询、文件读写、循环轮询）中定期检查
ctx.Err() - 避免在 defer 里做重操作（如关闭连接、清理资源），因为 ctx 可能在 defer 执行前已 cancel，导致 panic
- 不要复用同一个 cancel 函数多次调用——它只生效一次，重复调用无副作用但易误导
超时值必须从配置读，且 cancel 必须 defer
硬编码超时（如 3 * time.Second）会让服务难以适应不同环境（测试/预发/生产）和下游变化。应统一从 viper 或其他配置中心读取，例如 viper.GetDuration("upstream.timeout")。更关键的是：每次调用 context.WithTimeout 或 WithDeadline 返回的 cancel 函数，必须在作用域末尾 defer cancel()，否则 timer 不释放，长期运行的服务会缓慢泄漏 goroutine 和内存。
- 如果 cancel 需要跨函数传递（比如由调用方决定何时取消），就不要 defer，而是明确交给接收方负责调用
- select 中监听
ctx.Done()时，务必检查ctx.Err()类型：是context.DeadlineExceeded还是context.Canceled，二者日志含义完全不同 - 动态调整超时（如降级时延长）必须新建 ctx，不能修改已有 ctx 的 deadline
超时控制不是加个 timer 就完事，真正的难点在于全链路协同：客户端设 timeout、HTTP/gRPC 透传、服务端响应 cancel、配置可动态更新、cancel 资源不遗漏——任一环节断开，都会让超时失效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
