http.TimeoutHandler不会中断正在执行的handler，仅超时后返回503，而handler内部goroutine仍运行；真正可控超时需结合context.WithTimeout并在DB、HTTP等操作中显式传递和检查ctx。
http.TimeoutHandler 会中断正在执行的 handler 吗
不会。它只在超时后向客户端返回 503 Service Unavailable，但底层 handler 仍在运行 —— 这是最大误区。你写的 http.HandlerFunc 不会因超时自动停止，goroutine 继续执行，可能造成资源泄漏或重复写响应。
实操建议：
- 必须在 handler 内部主动检查
ctx.Done()（如果用了context.WithTimeout）或配合select做可取消操作 -
http.TimeoutHandler包裹的是整个 handler，不是某个函数调用；它不提供“中断执行”的能力，只是控制响应时机 - 常见错误：以为加了
TimeoutHandler就安全了，结果后台 goroutine 一直跑、数据库查询没 cancel、文件读取卡死
正确包裹 handler 的写法和参数含义
http.TimeoutHandler 构造函数签名是 func(h http.Handler, dt time.Duration, msg string) http.Handler，注意三点：
-
h必须是已实现http.Handler接口的值，不能直接传func(http.ResponseWriter, *http.Request)—— 需先用http.HandlerFunc转换 -
dt是从请求开始到返回响应的**总时限**（含读请求头、执行 handler、写响应），不是 handler 执行时间本身 -
msg是超时时返回的响应体内容，类型为text/plain; charset=utf-8，不支持 HTML 或自定义 header
示例：
h := http.TimeoutHandler(
http.HandlerFunc(myHandler),
5*time.Second,
"request timeout\n",
)
http.Handle("/api", h)
为什么有时超时没生效或延迟触发
超时计时器启动时机是 http.ServeHTTP 被调用时，也就是服务器完成请求解析、准备执行 handler 的那一刻。但以下情况会导致“看似没超时”或“超时延迟”：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 客户端慢速上传大 body：超时从 handler 开始执行算起，但 body 读取发生在 handler 内部（如
r.Body.Read），若没手动限制读取，实际超时会晚于预期 - 中间件干扰：如果你在
TimeoutHandler外又套了其他中间件（比如日志、鉴权），而它们耗时长，会压缩 handler 可用时间 - HTTP/2 或 keep-alive 连接下，某些 Go 版本存在计时器精度问题（1.19+ 已改善，但低版本仍建议用
context+net/http.Server.ReadTimeout做连接级防护）
更可靠的超时组合方案
单靠 http.TimeoutHandler 不足以覆盖所有场景。生产环境推荐分层设防：
- 连接级：设置
http.Server.ReadTimeout和WriteTimeout，防止慢客户端拖垮服务 - 路由级：用
http.TimeoutHandler控制关键接口整体耗时 - 业务级：handler 内部用
context.WithTimeout(r.Context(), ...)，并在 DB 查询、HTTP 调用、IO 操作中显式传递该 context
例如调用下游 API 时：
ctx, cancel := context.WithTimeout(r.Context(), 3*time.Second) defer cancel() resp, err := http.DefaultClient.Do(req.WithContext(ctx))
真正难处理的是 CPU 密集型逻辑 —— context 无法中断 goroutine，只能靠提前退出循环或分块处理来响应 cancel 信号。
