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。
以 CLI 为先的表单构建器，采用 BYOK 理念。通过JSON Schema 生成美观的 HTML 表单，使用您自己的 SMTP 服务器处理提交，存储响应...
- 优先使用带
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()
<pre class="brush:php;toolbar:false;">// 正确：传入 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,
KeepAlive: 30 * time.Second,
}).DialContext,
}
client := &http.Client{Transport: tr}
<p>req, _ := http.NewRequestWithContext(ctx, "GET", "<a href="https://www.php.cn/link/46b315dd44d174daf5617e22b3ac94ca">https://www.php.cn/link/46b315dd44d174daf5617e22b3ac94ca</a>", 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 重试——最终用户看到的超时表现可能完全偏离你的预期。
