context.WithTimeout没生效是因为未在关键位置检查ctx.Err()或未将ctx传入底层可取消操作；需确保I/O操作（如http.NewRequestWithContext）显式接收ctx，并在自定义协程中定期select监听ctx.Done()。
context.WithTimeout 为什么没生效
常见现象是调用 context.WithTimeout 后，协程依然跑满整个耗时，超时后 ctx.Done() 没被监听或没起作用。根本原因不是函数没触发，而是你没在关键位置检查 ctx.Err() 或没把 ctx 传到底层可取消的操作里。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有可能阻塞的 I/O 操作（如
http.Client.Do、time.Sleep、数据库查询）必须显式接收并响应ctx；比如http.NewRequestWithContext(ctx, ...)，而不是先建 request 再塞 context - 自定义协程中，必须在循环或等待逻辑里定期检查
select { case ，不能只在开头 check 一次 -
context.WithTimeout返回的ctx和cancel是成对的——哪怕超时自动 cancel，你也得在 defer 中调用cancel()，否则底层 timer 不释放，可能引发 goroutine 泄漏
http.Client 超时和 context 超时的区别在哪
很多人以为设了 http.Client.Timeout 就不用 context，其实两者控制点完全不同：前者只管单次请求总耗时（DNS + 连接 + 写请求 + 读响应），后者能提前中断正在执行的任意阶段，包括中间件、重试逻辑、甚至自定义 transport 层。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 生产环境建议「双保险」：
http.Client.Timeout防止底层连接卡死，context.WithTimeout控制业务侧整体流程（比如带重试的请求 + 缓存 fallback） - 如果用了
http.DefaultClient，它默认没有设置Timeout，此时全靠 context；但若设置了Timeout，它会在内部新建一个子 context，可能覆盖你传入的 context 的 deadline - 注意
http.Transport的ResponseHeaderTimeout等字段，它们不响应 context，必须单独配置
select + ctx.Done() 为什么会一直阻塞
典型错误是写成 select { case ，但 <code>ch 永远不发数据，而 ctx.Done() 又因为没调用 cancel() 或超时未到，导致 select 永远等下去——这和“协程没退出”是两回事，只是主线程卡在 select 上。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 永远在
select外层加超时兜底，或确保至少有一个分支能推进（比如用default做非阻塞轮询） -
ctx.Done()是一个只读 channel，关闭后会立即可读；但如果你在 goroutine 里反复启动新 select，又没清掉旧的，容易堆积无用 goroutine - 调试时打印
ctx.Err()值：如果是context.DeadlineExceeded，说明超时触发成功；如果是nil，大概率是还没到 deadline 或 context 根本没传递进去
goroutine 泄漏常被忽略的三个点
超时控制最隐蔽的问题不是功能失效，而是泄漏：goroutine 占着内存不退，日积月累拖垮服务。真正难排查的是那些“看起来已经结束”的协程。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有通过
go func() { ... }()启动的协程，只要涉及ctx，就必须有明确的退出路径——不能只依赖超时，还要处理ctx.Err() == context.Canceled的情况（比如用户主动取消） - 使用
sync.WaitGroup时，wg.Add(1)和defer wg.Done()必须成对出现在同一个 goroutine 内；如果defer在超时后才执行，而 wg 已被外部 wait，就会卡住 - HTTP handler 中启协程时，别直接用传入的
req.Context()；它在 handler 返回后会被 cancel，但你的协程可能还在跑——应该用context.WithCancel(context.Background())自建 root context，并手动管理生命周期
超时控制真正麻烦的地方不在 API 调用那几行代码，而在你是否把 context 像参数一样，一路透传进每个可能阻塞的函数签名里，以及是否为每一个 goroutine 明确画出了「什么情况下它必须停下来」的边界。
