context.withtimeout没生效是因为子context未显式传递到i/o函数中；需确保http用do+ctx、db用querycontext、grpc调用传ctx，且重试时每次新建带独立deadline的context。
context.WithTimeout 为什么没生效？
超时没触发，多半是 context.WithTimeout 创建的子 context 没传进真正执行 I/O 的地方。Golang 的 context 不会自动穿透到 goroutine 或第三方库内部——你得手动把 ctx 作为第一个参数显式传给所有支持 context 的函数（比如 http.Client.Do、database/sql.QueryContext、grpc.ClientConn.Invoke）。
常见错误现象：context.DeadlineExceeded 从不返回，goroutine 卡死，HTTP 请求永远 hang 住。
- 检查调用链：每个中间层是否都接收并向下传递
ctx，而不是用context.Background()或context.TODO()硬编码 - HTTP 客户端必须用
http.Client的Do方法（而非Get/Post），且传入带 timeout 的ctx - 数据库操作必须用
QueryContext、ExecContext等带 Context 的方法 - gRPC 调用必须通过
ctx参数控制，不能依赖客户端连接级别的 timeout
重试时该不该复用同一个 context？
不该。每次重试都应新建一个带独立 deadline 的 context，否则第一次超时后，后续所有重试都会立刻失败（因为父 context 已 cancel）。
正确做法是：在重试循环内，每次迭代都调用 context.WithTimeout，基于原始 timeout 和当前重试次数动态计算剩余时间（比如指数退避后还剩多少秒）。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
ctx, _ := context.WithTimeout(parentCtx, 5*time.Second)放在 for 外，所有重试共享这个 ctx - 推荐写法：每次重试前生成新
ctx，例如ctx, cancel := context.WithTimeout(parentCtx, time.Second * (2 - 注意
cancel()必须调用，否则可能泄漏 goroutine；建议 defer cancel()，但要确保它在本次重试结束时执行
Deadline 和 Timeout 到底该选哪个？
优先用 context.WithTimeout，除非你知道确切的绝对截止时间点。Deadline 更难维护：它依赖系统时钟，受 NTP 调整、时区变更、跨服务时间漂移影响；而 timeout 是相对值，语义清晰、可组合、易测试。
微服务间调用链中，上游传来的 deadline 可能已被消耗一部分，下游若再用 deadline 计算，容易误判剩余时间。
- 对外暴露 API 时，接收
ctx就够了，别自己解析 deadline - 内部服务间调用，统一用 timeout 构建子 context，便于统一调控（比如全局降级为 3s）
- 测试 mock 时，
WithTimeout更容易构造确定性行为；deadline 在单元测试里容易因时钟抖动失败
Cancel 信号被忽略的典型场景
不是所有操作都响应 cancel。比如标准库 net.Conn 的阻塞读写、某些 Cgo 封装的 SDK、或手写的无检查的 for 循环，都不会自动退出。
关键判断点：看函数签名是否接收 ctx context.Context。没有，就只能靠封装一层 select + channel + timeout 手动中断，或者改用支持 context 的替代实现。
-
time.Sleep不响应 cancel → 改用time.AfterFunc或 select 配合ctx.Done() - 自定义协程未监听
ctx.Done()→ 每次循环开头加select { case - 第三方 HTTP 库不支持 context → 换成
net/http原生 client，或确认其 latest 版本是否已支持 - 数据库驱动未升级 → 检查
github.com/lib/pq或github.com/go-sql-driver/mysql是否启用了 context 支持（如 mysql 的timeoutdsn 参数只是连接级，非 query 级）
context 不是银弹，它只提供信号通道；真正决定是否退出的，是你在每处阻塞点上是否做了响应。最容易被忽略的是中间件和工具函数——它们往往悄悄截断了 ctx 传递，或者压根没设计 context 接口。
