Go超时控制需context信号传播与底层原生机制协同；HTTP请求优先用context.WithTimeout实现粒度化、可透传的超时，http.Client.Timeout仅作全局兜底；TCP各阶段须用net.Dialer和Read/WriteDeadline分设超时，避免goroutine泄漏。
Go 里超时控制不是“加个 timer 就完事”，而是靠 context 信号传播 + 底层原生支持协同生效；用 time.After 或裸 select 配合 sleep，90% 场景会泄漏 goroutine 和连接资源。
HTTP 请求超时该用 http.Client.Timeout 还是 context.WithTimeout？
二者不互斥，但优先级和适用粒度不同：
-
http.Client.Timeout是客户端全局默认值，作用于整个请求生命周期（DNS → TLS → body 读完），不可动态调整，适合所有请求统一超时的内部工具脚本 -
context.WithTimeout是请求粒度控制，每次调用可设不同时间，还能透传 traceID、用户 ID 等元信息，网关、多租户服务必须用它 - 两者共存时，
context超时优先级更高——哪怕Client.Timeout设了 30s，ctx2s 到期也会立即中断 - 常见错误：
Do(req)没传req.WithContext(ctx)，或只设了Client.Timeout却在select里等time.After，结果超时完全不触发
TCP 连接各阶段超时怎么设才不泄漏？
不能靠外部轮询，得用 net 包原生机制分阶段控制：
- 连接建立（Dial）：用
&net.Dialer{Timeout: 5 * time.Second}，超时发生在内核connect()系统调用层，未连上即返回，绝无僵尸 goroutine - 读操作：每次调用
conn.Read()前，必须重设conn.SetReadDeadline(time.Now().Add(10 * time.Second))—— deadline 是绝对时间点，且只对下一次读生效 - 写操作：同样每次
Write()前调SetWriteDeadline()，不设写超时比读更危险，可能卡在 send buffer 满或对端窗口为 0 上数分钟 - 别用
SetDeadline()替代分开设置，读写超时需求通常不同（比如读要 5s，写只要 1s）
context.WithTimeout 为什么常“没效果”？
不是 context 失灵，而是信号没传下去或没被监听：
立即学习“go语言免费学习笔记（深入）”；
- 创建了
ctx, cancel := context.WithTimeout(...)，但没传给http.Do()、db.QueryContext()等函数，或下游函数压根不检查ctx.Done() - 自己写的阻塞逻辑（如循环读文件、长耗时计算）没在关键点插入
select { case ，context 就只是个摆设 - 忘了调
cancel()：不调不会泄漏 goroutine，但会泄漏 timer 和内部 channel，高频请求下内存缓慢增长 - 误判超时起点：计时从
WithTimeout()调用那一刻开始，不是从Do()或Read()开始——中间调度延迟、锁竞争都算进总时长
Handler 中超时嵌套和 panic 恢复时容易漏掉什么？
Web 服务里最容易出问题的两个盲区：
- HTTP handler 入口建的
ctx，必须在defer cancel()前覆盖所有退出路径：正常 return、http.Error、panic 恢复后、select的default分支，都得确保cancel()执行 - 不要在 for 循环里反复调
context.WithTimeout创建新 ctx——每次调用都启一个 timer，短循环会快速堆积 timer 对象 - 如果业务逻辑本身不支持 context（比如老版本 SQL 驱动），只能用
context.WithCancel+ 外部 goroutine 监控 + 主动cancel()，但要注意只调一次，且 cancel 后需额外同步（如 close done channel）通知主流程退出
真正难的不是写对那一行 ctx, cancel := context.WithTimeout(...)，而是确保信号能穿透每一层调用、每个 I/O 操作、每条 goroutine 路径，并在退出时干净释放 timer 和 channel。漏掉任意一环，超时就只是个心理安慰。
