微服务超时控制需通过context透传截止时间至db查询或下游调用，且各环节必须消费该ctx；单独调用context.withtimeout无效，因不自动中断操作，须配合querycontext等支持ctx的api使用。
微服务里的超时控制，不是“设个时间就完事”，而是靠 context 把截止时间从入口一路透传到最深的 DB 查询或下游 HTTP 调用，并确保每个阻塞点都响应这个信号。漏掉任意一环，超时就形同虚设。
为什么 context.WithTimeout 单独调用没用？
它只生成一个带截止时间的 ctx 和一个 cancel 函数，但不会自动中断任何操作。真正起作用的是：下游函数是否消费这个 ctx，以及你是否把 ctx 传给了它们。
- 常见错误：写了
ctx, cancel := context.WithTimeout(...)，却在db.Query()里用context.Background()—— 这等于超时信号根本没进数据库驱动 - 必须用支持 context 的替代函数：
db.QueryContext(ctx, ...)、http.NewRequestWithContext(ctx, ...)、grpc.Invoke(ctx, ...) -
time.Sleep(5 * time.Second)不会响应ctx.Done()；得写成select { case
HTTP 客户端超时为何卡在 DNS 或 TLS 阶段？
因为默认情况下，Go 的底层系统调用（如 getaddrinfo、connect）不响应 ctx.Done()，尤其在 Windows 或旧版 Go 中。这不是你代码错，是 runtime 限制。
- 必须显式配置
http.Transport：设置DialContext和TLSHandshakeTimeout，否则超时可能被底层阻塞拖长 -
http.Client.Timeout和context别共存——建议设为0，全由ctx控制，避免逻辑冲突 - Go 1.19+ 可临时启用
GODEBUG=netdns=cgo让 DNS 解析响应 cancel，但依赖 cgo；生产环境更稳的方式是自己封装带超时的 DNS 查询
子 goroutine 里不监听 ctx.Done() 就等于没超时
context 不杀 goroutine，只发信号。如果你启动了一个 goroutine 去轮询或等待 channel，而它内部没检查 ctx.Done()，那就算超时了，它还在跑。
- 循环中别写
for { select { case —— 缺少 <code>default或ctx.Done()分支，就会永远卡住 - 所有可能阻塞的操作都要加
select：比如db.QueryRowContext返回后还要.Scan()，这一步也可能阻塞，得用ctx包裹整个流程 - 子 context 的取消信号不会自动穿透“中间层”：如果某层用了
context.WithValue但没再套WithTimeout，下一层就收不到 deadline
真正难的不是写对那一行 context.WithTimeout，而是保证整条调用链上每个 I/O 点都接收到、检查并响应那个 ctx.Done() 信号——少一个，就等于整条链路失去超时保护。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
