context.deadlineexceeded 需结合 errors.is 判断并标注操作类型（http/db/协程），http.client.timeout 与 context.withtimeout 机制独立，须用 withcontext 透传取消信号，批处理需为每个子任务创建独立子 context，os.file.read 等系统调用不响应 ctx.done()。
查日志时发现 context.DeadlineExceeded，但不确定是哪一层超时
Go 中的 context.DeadlineExceeded 错误本身不带调用栈来源，只说明“某处 ctx 超时了”，但无法直接定位是 HTTP、DB 还是自定义逻辑触发的。最有效的方式是统一用 errors.Is(err, context.DeadlineExceeded) 包裹所有返回错误，并在日志中显式标注操作类型：
- HTTP 请求：记录
url、method和是否卡在reading body - 数据库操作：记录 SQL 片段（如
SELECT * FROM orders WHERE ...）和QueryContext调用点 - 自定义协程：在 select 分支里加
log.Printf("task %s interrupted: %v", name, ctx.Err())
避免只打 log.Println(err) —— 它会丢失上下文语义，也掩盖了到底是 client.Timeout 还是上游主动 cancel()。
为什么设置了 http.Client.Timeout，还是出现 context deadline exceeded
http.Client.Timeout 和 context.WithTimeout 是两套独立机制，且优先级不同。常见错误是只设了前者，却没传 context：
- 错误写法：
req, _ := http.NewRequest("GET", url, nil); client.Do(req)——req没带 context，client.Timeout会生效，但无法被外部 cancel 中断 - 正确写法：
req, _ := http.NewRequestWithContext(ctx, "GET", url, nil); client.Do(req)—— 此时ctx超时优先于client.Timeout，且能真正中断底层读取 -
client.Timeout只控制整个RoundTrip生命周期（DNS + dial + write + read headers + read body），但它不感知ctx.Done()；而WithContext才能把取消信号透传到连接层和响应体读取环节
批处理循环里每个子任务都用同一个 ctx，结果一个超时全盘失败
批量任务（比如遍历 100 条记录逐个调用下游 API）必须为每个子任务创建独立子 context，否则一个失败会 cancel 掉全部：
- 错误做法：
for _, item := range items { go processItem(ctx, item) }—— 所有 goroutine 共享同一 ctx，任一超时或 cancel 都会让其余任务立即退出 - 正确做法：
for _, item := range items { item := item; ctx := ctx; go func() { subCtx, cancel := context.WithTimeout(ctx, 5*time.Second); defer cancel(); processItem(subCtx, item) }() } - 注意变量捕获：循环变量
item必须在 goroutine 外显式重绑定（item := item），否则所有 goroutine 会读到最后一个值 - 如果需等待全部完成，用
errgroup.Group替代裸go+sync.WaitGroup，它自动集成 context 取消传播
os.File.Read 或 io.Copy 卡住，ctx.Done() 完全没反应
os.File 的 Read、Write 是纯同步阻塞系统调用，不接受 context 参数，也不响应 ctx.Done()。这是标准库设计限制，不是 bug：
- 不要指望
select { case —— <code>src.Read(buf)在 case 分支里会先执行，一旦阻塞就卡死整个 select - 正确方案一（推荐）：用 Go 1.19+ 的
io.CopyContext(dst, src, ctx)替代io.Copy，它在每次内部Read后检查ctx.Err() - 正确方案二：手动分块，每次
Read前先select监听ctx.Done()，把Read放在default分支，避免阻塞 select - 切记：文件句柄泄漏风险极高 —— 超时后必须显式
dst.Close()、src.Close()，不能依赖 defer（因为 goroutine 可能已卡住）
真正的“彻底排查”不在于堆更多 timeout，而在于确认每一层 I/O 是否真的收到了取消信号 —— HTTP、gRPC、SQL、文件读写，各自有各自的透传路径，漏掉任何一层，超时就只是假象。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
