http.TimeoutHandler 经常不生效，根本原因是它仅对 Handler 函数体内的阻塞有效，无法控制其启动的 goroutine、DB 查询或外部 HTTP 调用；真正可控的超时必须依赖 context.WithTimeout 并在各耗时操作中显式传递和使用 ctx。
http.TimeoutHandler 为什么经常不生效
根本原因不是它写错了，而是它只对 Handler 函数体内的阻塞生效，对 handler 启动的 goroutine、数据库查询、外部 HTTP 调用等完全无感。它本质是给 http.ServeHTTP 这一层加了个外层计时器，一旦内部 handler 返回（哪怕只是返回了，没写响应），超时逻辑就终止了。
常见错误现象：TimeoutHandler 设了 5 秒，但后端调用第三方 API 卡了 20 秒，客户端却等到 20 秒才收到响应，或者直接报 net/http: request canceled —— 这说明超时没拦住，反而是客户端先断开了。
- 它只包装
http.Handler，不能穿透到业务逻辑内部 - 如果 handler 里用了
go func() { ... }()启协程但没做上下文取消，超时后协程还在跑 - 它返回的默认错误页是纯文本
"503 Service Temporarily Unavailable"，没法自定义 JSON 响应
真正可控的超时必须靠 context.WithTimeout
http.TimeoutHandler 是“门外的哨兵”，context.WithTimeout 才是“进屋后发给每个工人的倒计时牌”。所有可能耗时的操作——DB 查询、HTTP client 调用、文件读取——都得显式接收并传递 ctx 参数。
使用场景：你写了一个 getUserData 函数，里面要查 MySQL、再调一次 Redis、最后请求一个内部服务，这三步都得支持 cancel。
立即学习“go语言免费学习笔记（深入）”；
- HTTP client 必须用
http.DefaultClient.Do(req.WithContext(ctx))，不能用http.Get - database/sql 的
QueryContext/ExecContext替代Query/Exec - 自己写的异步操作，要用
select { case 主动监听取消 - 别在 handler 开头就
ctx, _ := context.WithTimeout(r.Context(), 5*time.Second)就完事——得把ctx一路透传到底
TimeoutHandler + context 的组合姿势
两者不是二选一，而是分层防御：TimeoutHandler 拦住整个 handler 执行时间上限（防死循环、防 panic 后卡住），context 控制每一步子操作的粒度超时（防慢查询、防下游雪崩）。
参数差异明显：http.TimeoutHandler 第三个参数是超时后的 http.Handler，用来返回兜底响应；而 context.WithTimeout 返回的是带截止时间的 context.Context，需要你手动处理 ctx.Err()。
handler := http.TimeoutHandler(http.HandlerFunc(myHandler), 5*time.Second, "timeout\n")
http.Handle("/api", handler)
在 myHandler 内部：
- 第一行就提取
ctx := r.Context() - 后续每一步耗时操作前，都派生新 ctx：
dbCtx, cancel := context.WithTimeout(ctx, 2*time.Second) - 记得
defer cancel()，避免 context 泄漏
容易被忽略的 context 传播陷阱
最常踩的坑不是不会用 context.WithTimeout，而是「以为传了，其实没传进去」。比如函数签名没改、中间封装层丢掉了 ctx、或用 channel 通信时没把 ctx 带过去。
性能影响很小，但兼容性极关键：Go 1.7+ 才正式支持 context 在标准库中深度集成；低于这个版本的 database/sql 或旧版 http.Client 不认 Context 方法。
- 检查所有依赖库是否支持 context 接口，比如
github.com/go-sql-driver/mysqlv1.5+ 才完整支持QueryContext - 别在 struct 字段里存
context.Context，它不是用来长期持有的 - 日志打点时用
log.WithContext(ctx)，否则超时发生时你连哪次请求卡住都找不到
超时控制真正的复杂点从来不在语法，而在「谁负责取消」「谁负责监听」「谁负责清理资源」这三件事是否对得上号。少一个，就等于埋了个定时协程。
