context.withtimeout 不能跨 http 边界自动生效，因其仅限当前进程内存有效，下游服务无法感知；需通过请求头（如 x-request-timeout）传递超时语义，并在下游解析后重建 context。
context.WithTimeout 为什么不能跨 HTTP 边界自动生效
因为 context.WithTimeout 创建的 context 只在当前进程内存中有效，HTTP 请求发出去后，下游服务收不到你的 ctx.Deadline() 或 ctx.Done()。你设了 5 秒，但对方可能用默认 30 秒，甚至压根没读超时头——链路就断了。
真正能跨服务传递的是「超时语义」，不是 context 对象本身。必须把意图编码进请求头（比如 X-Request-Timeout），下游解析后再调用 context.WithTimeout 创建新 context。
- 上游写头：
req.Header.Set("X-Request-Timeout", "4500")（单位毫秒） - 下游读头：
timeout, _ := strconv.ParseInt(header.Get("X-Request-Timeout"), 10, 64)→context.WithTimeout(parentCtx, time.Duration(timeout)*time.Millisecond) - 单位必须一致：Go 的
time.Millisecond是int64，别用 float 或秒级字符串直接 parse - 下游解析失败时，应 fallback 到一个安全默认值（如
3 * time.Second），而不是沿用父 context 的 deadline
HTTP 客户端侧必须同时配 context 和 Transport 底层超时
只靠 context.WithTimeout 不够。它只能中断阻塞的 goroutine，但 TCP 连接可能卡在 SYN、TLS 握手或服务器未响应 header 阶段，实际耗时远超设定值。
必须显式配置 http.Transport 的三类底层超时，并确保它们 ≤ 上游传来的逻辑超时：
-
Transport.DialContext：控制建连（含 DNS 解析），建议 ≤ 总超时的 1/3 -
Transport.TLSHandshakeTimeout：TLS 握手，通常5 * time.Second足够 -
Transport.ResponseHeaderTimeout：从发完请求到收到 status line 的时间，应 ≤ 剩余超时 - 别同时设
http.Client.Timeout和 context 超时——前者语义模糊，容易掩盖问题；后者负责细粒度中断，前者兜底防卡死
下游服务 handler 中如何正确继承并透传超时
Go 的 http.Request.Context() 已绑定请求生命周期，包含客户端断连信号和服务器全局超时（如 http.Server.ReadTimeout）。你不能在 handler 里新建 context.Background()，否则会丢失取消信号。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
所有下游调用（DB 查询、HTTP 调用、goroutine 启动）都必须显式接收并传递这个 req.Context()：
- 加 DB 超时：
ctx, cancel := context.WithTimeout(req.Context(), 5*time.Second)，不是context.WithTimeout(context.Background(), ...) - 发起 HTTP 调用：
req = req.WithContext(ctx)，再client.Do(req)；不要用http.Get或裸client.Do - 启动子 goroutine：若需独立生命周期，用
context.WithCancel(req.Context())并在 goroutine 内部控制cancel，而非复用外部cancel - 自己写的轮询或 sleep 逻辑，必须用
select监听ctx.Done()，不能只靠time.Sleep
cancel() 必须显式调用，defer 只是兜底
context.WithTimeout 返回的 cancel 函数不是可选项，而是必需项。不调用它，底层 timer 和 Done() 通道不会释放，高频服务运行数小时后内存与 goroutine 数量会缓慢但持续上涨。
正确写法一定是：ctx, cancel := context.WithTimeout(...)，且 cancel() 要在所有出口处执行：
- 包括正常
return、error return、panic恢复后、select的default分支里 -
defer cancel()是基础保障，但无法覆盖panic未recover、或提前return却遗漏cancel的情况 - 即使
ctx.Err() == context.DeadlineExceeded已发生，仍需调用cancel()，否则定时器继续驻留 - 启动新 goroutine 时，如果它需要独立生命周期，应该用
context.WithCancel(parent)并在 goroutine 内部控制cancel，而不是复用外部cancel
最易被忽略的点是：超时起点从 WithTimeout 调用那一刻开始，不是从 HTTP 请求发出、数据库查询启动或 goroutine 真正执行那一刻开始。这个时间差在高并发或长链路中会被放大，必须心里有数。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
