withdeadline 总无效的根本原因是未调用或过晚调用 cancelfunc，且需主动监听 ctx.done() 并检查 ctx.err()；其 deadline 会静默截断为父 context 的截止时间，语义上适用于绝对截止时刻，精度受系统时钟影响。
WithDeadline 为什么总返回 cancelFunc 却没效果？
根本原因：没调用 cancelFunc，或者调用太晚。Go 的 context.WithDeadline 不会自动触发超时逻辑，它只在你主动调用 ctx.Done() 对应的 channel 或显式调用 cancelFunc 时才生效。
-
ctx.Done()是一个只读 channel，必须用select监听它，否则超时信号永远被忽略 - 如果业务函数没检查
ctx.Err()，或没把 ctx 传到底层调用（比如http.NewRequestWithContext），deadline 就形同虚设 - 时间精度受系统定时器影响，Linux 上通常有 ~10–15ms 偏差，别拿它做毫秒级精确控制
WithDeadline 和 WithTimeout 到底该选哪个？
选 context.WithDeadline 当你知道「绝对截止时刻」（比如“必须在 2024-10-15T14:30:00Z 前完成”）；选 context.WithTimeout 当你只知道「最长允许耗时」（比如“最多等 5 秒”）。
-
WithDeadline(ctx, time.Now().Add(5*time.Second))和WithTimeout(ctx, 5*time.Second)表面等价，但语义不同：前者依赖系统时钟，后者基于相对时长 - 如果系统时间被 NTP 调整或手动修改，
WithDeadline可能提前或延后触发；WithTimeout更稳定 - HTTP 客户端默认用
WithTimeout，因为请求发起时间不确定，用相对超时更合理
嵌套 WithDeadline 容易踩的坑
子 context 的 deadline 不能晚于父 context 的 deadline —— Go 会自动截断为父 context 的截止时间，且不报错。
- 假设父 ctx 截止时间为
time.Now().Add(3 * time.Second)，你对它调用context.WithDeadline(parentCtx, time.Now().Add(10 * time.Second))，实际得到的仍是 3 秒后截止 - 这种截断是静默的，不会 panic，也不会 warn，只能靠日志或调试时打印
ctx.Deadline()验证 - 若需延长超时，必须从原始 background 或 todo ctx 重新派生，不能基于已有带 deadline 的 ctx 再套一层
如何验证 WithDeadline 真正生效？
最直接的办法：写个可阻塞的测试函数，用 select 同时监听 ctx.Done() 和模拟耗时操作，观察是否如期退出。
ctx, cancel := context.WithDeadline(context.Background(), time.Now().Add(100*time.Millisecond))
defer cancel()
<p>done := make(chan struct{})
go func() {
time.Sleep(200 * time.Millisecond) // 故意超时
close(done)
}()</p><p>select {
case </p><p>注意：<code>ctx.Err()</code> 在 deadline 到达后才变为非 nil，之前是 <code>nil</code>；别在 select 外部轮询判断，那会浪费 CPU。</p><p>真正难的是让整个调用链都尊重 context —— 从 HTTP 请求、数据库查询到自定义 goroutine，每一步都要检查 <code>ctx.Err()</code> 并及时返回。漏掉任意一环，deadline 就只是个摆设。</p>golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
