Go连接超时控制必须联动context，仅设http.Client.Timeout或数据库初始化参数无效；需通过Transport.DialContext、TLSHandshakeTimeout等精细配置，并用QueryContext、NewRequestWithContext等支持context的API，配合r.Context()派生、显式cancel及请求头透传超时语义。
Go 里连接超时控制不能只靠 http.Client.Timeout 或数据库驱动的初始化参数，必须和 context 联动才能真正中断阻塞、释放资源。单独设超时字段，只会在最后兜底，中间卡在 DNS、TCP 握手、TLS 协商或读响应头时，goroutine 依然挂着不退。
HTTP 客户端连接超时必须配 Transport + context
默认 http.DefaultClient 的 Transport 对 DNS 和建连没有精细控制，context.WithTimeout 在这些阶段无法生效——因为底层系统调用（尤其 Windows 或旧内核）不响应 cancel 信号。
-
Transport.DialContext必须设置：它接管 TCP 连接建立，能响应ctx.Done()，建议设为总超时的 1/3（比如总 5s，这里设 1.5s） -
Transport.TLSHandshakeTimeout要显式设（如5 * time.Second），否则 TLS 握手可能卡住十几秒 -
Transport.ResponseHeaderTimeout控制“发完请求到收到 status line”的时间，避免服务端迟迟不返回 header -
client.Timeout建议设为0，避免和 context 冲突；它的存在只是兜底，不是主力
示例：
tr := &http.Transport{
DialContext: (&net.Dialer{Timeout: 1500 * time.Millisecond}).DialContext,
TLSHandshakeTimeout: 5 * time.Second,
ResponseHeaderTimeout: 3 * time.Second,
}
client := &http.Client{Transport: tr}数据库连接池初始化超时 ≠ 查询超时
sql.Open 里的 timeout 参数（如 MySQL DSN 中的 timeout=5s）只影响连接池首次建连，对后续任何 Query、Exec 都无效。真正在查表时卡住，必须用 QueryContext。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 驱动版本要够新：MySQL 驱动 ≥ v1.6.0，PostgreSQL ≥ v1.12.0，否则
QueryContext不真正中断底层 socket - 别写
db.Query("SELECT ...")，必须用db.QueryContext(ctx, "SELECT ...") - 如果查询返回
rows，记得检查err是否为context.DeadlineExceeded或context.Canceled，而不是忽略 - 连接池本身没超时机制，
SetConnMaxLifetime和SetMaxIdleConns是另一回事，别混淆
Handler 里 context 派生顺序决定超时是否可靠
很多超时失效，是因为在 handler 开头就用 context.Background() 或提前创建了固定 ctx，结果既收不到客户端断连信号，也无法继承 server 层配置的 ReadTimeout。
- 起点必须是
r.Context()，不是context.Background() - 如果要加业务级超时（比如 DB 查询最多 2s），用
context.WithTimeout(r.Context(), 2*time.Second)，不是嵌套在另一个 timeout ctx 里 - 所有下游操作——HTTP 请求、DB 查询、自定义 goroutine——都得把派生出的 ctx 当参数传进去，不能闭包捕获外层变量
- panic 恢复后、
return前、select的default分支里，都要确保cancel()被调用，defer 不够
跨服务调用时超时不会自动传递
context.WithTimeout 对象不会随 HTTP 请求自动序列化过去。下游服务拿到的只是一个普通 request，req.Context() 是新的、无 deadline 的 context。
- 上游需手动写请求头：
req.Header.Set("X-Request-Timeout", strconv.FormatInt(4500, 10))（单位毫秒） - 下游解析该头，转成
time.Duration，再调context.WithTimeout(parentCtx, timeout) - 务必 fallback：如果头不存在或解析失败，用一个安全默认值（如
3 * time.Second），而不是沿用父 ctx 的 deadline - gRPC 场景优先用
grpc.Timeout和grpc.WaitForReady(false)，避免重试掩盖真实超时点
最易被忽略的一点：超时起点是 context.WithTimeout 调用那一刻，不是你发起网络请求的时刻。中间任何锁竞争、GC STW、调度延迟都会吃掉这部分时间——所以别在 handler 入口就建好超时 ctx，而应在真正要发请求前一刻才创建。
