context.withtimeout仅关闭done通道，需手动监听并响应取消信号；必须在阻塞点检查ctx.err()或用select监听ctx.done()，否则超时无效。
Context.WithTimeout 会自动取消，但必须手动接收取消信号
Go 的 context.WithTimeout 不会“自动中断”正在运行的函数，它只负责在超时后把 ctx.Done() 的 channel 关闭。你得自己监听这个 channel，并在收到关闭信号时主动退出逻辑——否则超时就形同虚设。
常见错误是调用了 WithTimeout 却没检查 ctx.Err() 或没 select ctx.Done()，导致 goroutine 一直跑下去，甚至引发资源泄漏。
- 必须在关键阻塞点（如
http.Client.Do、time.Sleep、数据库查询）前或循环中检查ctx.Err() != nil - 如果函数本身支持 context（如
http.NewRequestWithContext、sql.DB.QueryRowContext），优先用它，而不是自己轮询 - 不要在 defer 中依赖
ctx.Done()——defer 执行时 context 可能已过期，但业务逻辑早已失控
select 配合 ctx.Done() 是最稳妥的等待方式
当你需要等待某个异步操作（比如一个 goroutine 完成、一个 channel 接收）且带超时，select 是唯一推荐做法。硬写 time.After 或 time.Sleep 会绕过 context 的取消传播机制，无法响应提前取消。
例如，下面这段代码会让超时控制失效：
time.Sleep(5 * time.Second) // 错！无视 ctx 是否已被 cancel
正确写法是：
select {
case
- 所有阻塞操作都应包裹在
select中，至少包含ctx.Done()分支 - 如果操作本身不接收 context（比如第三方库的同步调用），只能靠启动 goroutine + channel + select 来“包装”
- 注意：
ctx.Done()关闭后，再次读取会立即返回零值，所以不能用if 判断，必须用 <code>select
传递 context 时别丢掉，尤其跨 goroutine 或中间件
超时信号丢失最常见的原因是 context 没被一路传到底。比如 HTTP handler 中创建了带 timeout 的子 context，但调用下游 service 时传的是 context.Background()，那上游的超时对下游完全无效。
- 每个函数签名若涉及 I/O 或可能阻塞，都应接受
ctx context.Context参数，并向下透传 - goroutine 启动时必须显式传入 context，不能在 goroutine 内部重新
context.Background() - 中间件（如日志、鉴权）若启动新 goroutine 处理耗时任务，也要确保把原始请求 context 传进去，而不是用新 context
WithTimeout 和 WithDeadline 的区别影响实际行为
很多人以为 WithTimeout 就是 “N 秒后一定停”，其实它基于从调用时刻起计时；而 WithDeadline 是指定一个绝对时间点。当系统时间被调整（如 NTP 同步回拨），WithTimeout 可能意外延长，WithDeadline 更稳定。
不过绝大多数 Web/微服务场景用 WithTimeout 更自然，只要注意两点：
-
WithTimeout返回的cancel函数必须调用，否则底层 timer 不释放，可能造成 goroutine 泄漏 - 超时时间不是“最多执行多久”，而是“从 now 开始，最多等多久”，所以嵌套调用时要预留上层开销（比如总超时 3s，HTTP client 设 2.5s）
- 测试时别用
time.Now().Add()算 deadline——直接用WithDeadline更清晰可读
真正容易被忽略的是：context 取消后，已启动但未完成的 goroutine 不会自动终止，你得靠 channel、flag 或其他协作机制让它感知并退出。超时只是发个“通知”，不是按开关。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
