Golang Web开发中如何设置超时控制_Golang context超时使用

http Server超时需设ReadTimeout（建连到读完header）、WriteTimeout（接收请求到写出响应）、IdleTimeout（keep-alive空闲时长）；Handler内用context.WithTimeout控制业务逻辑；Client端必须用context而非client.Timeout实现分阶段超时。

HTTP Server 启动时设置全局读写超时

go 的 http.Server 本身不依赖 context 控制连接生命周期，而是通过字段直接配置超时。忽略这点容易误以为加了 context.WithTimeout 就能控制请求连接建立或响应写出——其实不能。

常见错误是只在 handler 里用 context.WithTimeout，结果客户端已断连、服务端还在读 body 或写 response，导致 goroutine 泄漏。

• ReadTimeout：从连接建立到读完 request header 的最大时间（含 TLS 握手）
• WriteTimeout：从接受 request 到完成 response 写出的总耗时（含 handler 执行 + write header + write body）
• IdleTimeout：HTTP/1.1 keep-alive 或 HTTP/2 连接空闲时长，推荐设为 30–60s

示例：

srv := &http.Server{     Addr:         ":8080",     Handler:      mux,     ReadTimeout:  5 * time.Second,     WriteTimeout: 10 * time.Second,     IdleTimeout:  60 * time.Second, }

Handler 内部用 context.WithTimeout 控制业务逻辑

这是 context 超时最常被正确使用的场景：限制数据库查询、rpc 调用、文件读写等阻塞操作。但要注意，超时 context 必须传给所有可能阻塞的函数，且这些函数得主动检查 ctx.Done()。

立即学习“go语言免费学习笔记（深入）”；

典型陷阱是调用不支持 context 的旧库（如某些 sql 驱动没提供 QueryContext），或忘记把 ctx 透传进子 goroutine。

• 优先使用带 Context 后缀的方法：如 db.QueryContext(ctx, ...)、client.Do(req.WithContext(ctx))
• 自定义阻塞操作需定期 select ctx.Done()，例如循环读文件时每读一块检查一次
• 不要用 time.AfterFunc 模拟超时——它无法取消底层 I/O，只是提前返回错误

示例：

func handler(w http.ResponseWriter, r *http.Request) {     ctx, cancel := context.WithTimeout(r.Context(), 3*time.Second)     defer cancel() 
// 正确：传入 context rows, err := db.QueryContext(ctx, "SELECT * FROM users WHERE id = ?", r.URL.Query().Get("id")) if err != nil {     if errors.Is(err, context.DeadlineExceeded) {         http.Error(w, "timeout", http.StatusgatewayTimeout)         return     }     http.Error(w, err.Error(), http.StatusInternalServerError)     return } defer rows.Close() // ...
}
HTTP Client 请求超时必须用 context，不能只靠 client.Timeout
http.Client.Timeout 只控制整个请求的“总时间”，但它会覆盖掉 context 的 deadline，且无法区分“dns 解析慢”“TLS 握手卡住”“body 上传中止”等阶段。生产环境建议禁用 client.Timeout，统一用 context 管理。

DNS 和连接建立阶段超时：由 context 控制，但需配合自定义 http.Transport 的 DialContext 
TLS 握手超时：同样走 DialContext，在 tls.Dialer 中传入 ctx 
请求发出后响应读取超时：需在 RoundTrip 返回前手动检查 ctx.Done()，或用支持 context 的第三方 client（如 golang.org/x/net/http2 默认支持）

示例（精简版）：
tr := &http.Transport{     DialContext: (&net.Dialer{         Timeout:   3 * time.Second,         keep-alive: 30 * time.Second,     }).DialContext, } client := &http.Client{Transport: tr} 
req, _ := http.NewRequestWithContext(ctx, "GET", "https://www.php.cn/link/46b315dd44d174daf5617e22b3ac94ca", nil) resp, err := client.Do(req) // ctx 会作用于 DNS、connect、TLS、read response header/body 全流程
超时嵌套和父子 context 容易引发意外取消
常见错误是在一个已有 timeout 的 request context 上再套一层更短的 context.WithTimeout，结果 handler 还没开始执行就被父 context 取消。比如中间件设置了 5s 超时，handler 又设了 3s，但父 context 已在 2s 后因网络延迟触发取消——子 context 立即失效。

避免无意义嵌套：除非明确需要更细粒度控制（如 DB 查询限 2s，缓存限 100ms），否则直接用 r.Context() 
用 context.WithCancel + 手动 cancel 更可控，尤其在异步任务中（如启动 goroutine 发送消息后需确保不泄漏）
日志中打印 ctx.Err() 时注意：可能是 context.Canceled（主动 cancel）或 context.DeadlineExceeded（自然超时），二者语义不同，排查方向也不同

真正难处理的是跨系统超时对齐：比如你设了 3s，但下游服务 SLA 是 5s，网关又加了 2s 重试——最终用户看到的超时表现可能完全偏离你的预期。