context.withtimeout仅控制显式监听ctx.done()的逻辑，dns/tcp/tls等底层阻塞阶段默认不响应；需配合http.transport.dialcontext、tlshandshaketimeout等分层设防，并显式调用cancel()防泄漏。
context.WithTimeout 不是“给函数加个倒计时”，它只控制你代码里显式监听 ctx.Done() 的那部分逻辑；建连、DNS、TLS 握手这些底层阻塞阶段默认不响应它。
为什么 HTTP 请求设了 100ms 超时却卡了 3 秒才返回
常见现象：ctx.Err() 一直是 nil，直到整个请求结束才突然变成 context.DeadlineExceeded。
- 根本原因：Go 标准库的
net/http在发起http.Do()前的阶段（如 DNS 解析、TCP connect、TLS handshake）使用的是系统调用，这些调用在多数平台（尤其是 Windows 和旧版 Linux 内核）上不检查ctx.Done() -
context.WithTimeout的 timer 是从调用该函数那一行执行完立刻启动的，不是从http.Do()开始算 —— 中间任何初始化耗时（比如读配置、拼 URL）都会吃掉超时预算 - 真正受 context 控制的，只有
http.Do()返回后等待响应体（response body）读取的阶段
怎么让 HTTP 客户端真正响应超时
靠单一层 context.WithTimeout 不够，得在 transport 层做分段设防：
- 用
http.Transport.DialContext替换默认 dialer，它接收context.Context，能中断 DNS 和 TCP 连接 - 设置
Transport.TLSHandshakeTimeout控制 TLS 握手时间（单位是time.Duration） -
Transport.IdleConnTimeout和Transport.KeepAlive防止连接池长期挂起 - 如果必须兼容老环境，可临时启用
GODEBUG=netdns=cgo让 DNS 解析响应 cancel，但上线前务必验证 cgo 是否可用
cancel() 必须配对调用，defer 不等于安全
写成 defer cancel() 看似省事，但极易漏调：
- 函数有多个
return分支时，defer只在最后出口执行 —— 中间出错提前 return 就跳过了 -
cancel()是幂等的，重复调用无害，但掩盖了控制流设计缺陷 - 正确做法：把主逻辑包进一个匿名函数，或在每个
return前显式调用cancel()；若真要用 defer，确保函数是单出口 - 不调用
cancel()的后果不是立刻崩溃，而是泄漏一个 goroutine + 一个未停止的 timer，积少成多会拖慢整个服务
子 Context 超时不能突破父 Context 剩余时间
这是级联取消的底层约束，不是 bug：
- 假设父 ctx 剩余 2s，你用
context.WithTimeout(parent, 10*time.Second)创建子 ctx，它实际最多活 2s —— 超时 timer 会按父 ctx 剩余时间重设 - HTTP 中间件中常见的错误：为每个 handler 单独设 10s 超时，但上游网关只给了 5s，结果所有下游调用都在 5s 后被强制终止，无法区分是自身慢还是上游压测导致
- 推荐做法：入口处统一设 timeout，下游复用
r.Context()，必要时用context.WithTimeout(ctx, shorter)缩短，但绝不延长
真正难的不是写对那几行 ctx, cancel := context.WithTimeout(...)，而是判断哪些操作该传 ctx、哪些阶段要靠 transport 配置兜底、以及 cancel 到底该在哪个代码点触发 —— 这些边界往往藏在 net 底层行为和业务 SLA 要求之间。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
