go微服务context超时失效主因是未透传至底层i/o、未监听ctx.done()或未调用cancel()；http.client.do不超时因req.withcontext未被transport响应，需显式配置dialcontext等字段并确保do前绑定ctx。
Go 微服务里 context 超时控制失效，90% 是因为没传到底、没监听或没调用 cancel() —— 不是 context.WithTimeout 有问题，而是链路断在了中间某一层。
为什么 http.Client.Do 用了 context 还是不超时
根本原因：你可能只改了 req.WithContext(ctx)，但没确保 client.Do() 真的用上了这个 req；或者底层 transport 没响应 cancel 信号。
-
http.Client.Timeout和context是两套机制：Timeout控整个请求生命周期（DNS+连接+读响应头），但不包括响应体流式读取；context要靠http.NewRequestWithContext()注入，并在 transport 层真正监听ctx.Done() - Go 1.19 前，
DialContext、TLSHandshakeTimeout等默认不感知 context，必须显式配置http.Transport的DialContext字段 - 错误写法：
req = req.WithContext(ctx); client.Do(req)—— 看似更新了 req，但某些自定义 transport 或旧版 client 可能忽略它；稳妥写法是client.Do(req.WithContext(ctx))，确保上下文在Do调用前就绑定 - 如果下游服务返回大 payload 或启用 streaming，
resp.Body.Read()会阻塞，此时必须在读循环里插入select { case ，否则超时信号永远收不到
gRPC 和 GORM 调用中 context 怎么透传才有效
gRPC 和 GORM 都原生支持 context，但“支持”不等于“自动生效”——你得主动把带超时的 ctx 传进去，且服务端/驱动也得配合检查。
- gRPC 客户端：所有方法第一个参数必须是
ctx，例如client.GetUser(ctx, req)；grpc.Dial()中的grpc.WithTimeout已弃用且不生效，别再用 - gRPC 服务端：不能只在 handler 开头 check 一次
ctx.Err()，要在每个耗时操作（如 DB 查询、文件读取）前都select监听ctx.Done()，否则客户端取消后 server 还在跑无意义逻辑 - GORM：优先用
db.WithContext(ctx).Find(&u)，而不是依赖全局DefaultContextTimeout；后者只对未显式传 ctx 的调用兜底，无法应对动态超时场景（比如降级时缩短 timeout） - GORM 事务更敏感：事务内多个语句共享同一个 ctx，一旦超时，整个事务应快速回滚；务必用
db.WithContext(ctx).Transaction(...)，别在事务函数内部硬写context.Background()
WithTimeout 和 cancel() 必须成对出现，否则泄漏
context.WithTimeout 内部启动了一个 time.Timer，不调用 cancel() 就不会停止它 —— timer 一直活着，goroutine 不退出，内存不回收。
- 常见错误：
ctx, _ := context.WithTimeout(...)，丢弃cancel函数；正确写法永远是ctx, cancel := context.WithTimeout(...); defer cancel() -
defer cancel()在 early return 分支里也会被跳过，所以如果有多个 return 点，要么统一用defer，要么在每个 return 前手动调用cancel() - 不要复用同一个
cancel()多次：它只能调用一次，第二次调用无效果，但也不会报错，容易误以为“已清理” -
context.WithDeadline同理，而且如果传入的时间点早于当前时间，ctx.Err()立即返回context.DeadlineExceeded，这种错误常被静默吞掉，导致接口秒失败却查不出原因
监听 ctx.Done() 的唯一正确方式是 select
ctx.Done() 是 channel，不是布尔值；把它当条件判断或循环条件，基本等于放弃超时控制。
- 错误写法：
if ctx.Done() != nil { ... }——ctx.Done()永远非 nil，这个判断恒为 true - 错误写法：
for ctx.Err() == nil { ... }——ctx.Err()在取消前恒为nil，等价于死循环 - 正确写法只有：
select { case ，且必须嵌入到所有等待点：HTTP 响应读取、DB 查询轮询、channel receive、sleep 等 - 如果加了
default分支又没 sleep，就是忙等；高频轮询建议用带超时的select，比如case
最易被忽略的一点：context 超时不是“设置就生效”的魔法，它是一条需要手工打通的信号链 —— 从 handler 的 r.Context() 开始，每一层函数都要显式接收、传递、监听，任何一环漏掉，整条链就断了。尤其是中间件、封装库、自定义 transport 这些“看不见”的地方，最容易成为超时失效的黑盒。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
