context.WithDeadline要求传入未来时间，否则立即取消；它表示绝对截止点，不同于WithTimeout的相对时长；子context不继承父deadline，需显式传递并取最小值；cancel函数必须手动调用以防泄漏。
context.WithDeadline 传入的时间必须是未来时间，否则会立即取消
调用 context.WithDeadline 时如果传入一个过去或当前时刻的 time.Time，返回的 context 会立刻进入 Done 状态，ctx.Done() 立即可读，ctx.Err() 返回 context.DeadlineExceeded。这不是 bug，而是设计行为——deadline 是“绝对截止点”，不是“持续时长”。
常见错误是误把相对偏移（比如 5 秒后）直接传给 WithDeadline，而没用 time.Now().Add(5 * time.Second) 计算出绝对时间：
// ❌ 错误：time.Now() 是当前时刻，deadline 已过 ctx, cancel := context.WithDeadline(ctx, time.Now()) <p>// ✅ 正确：明确计算未来绝对时间点 deadline := time.Now().Add(10 * time.Second) ctx, cancel := context.WithDeadline(ctx, deadline)
- 务必检查
deadline.After(time.Now())，尤其在测试或时钟被 mock 的环境里 - 跨服务传递 deadline 时，注意系统时钟漂移——不同机器时间不一致会导致提前或延迟取消
- 若需基于请求接收时间设 deadline（如 HTTP server），应在 handler 开头立刻记录
start := time.Now()，再算 deadline，避免中间逻辑拖慢计算
WithDeadline 和 WithTimeout 的语义区别直接影响超时控制粒度
context.WithDeadline 接收 time.Time，表示“绝对时间点”；context.WithTimeout 接收 time.Duration，表示“从调用时刻起多少时间后超时”。两者底层都生成 deadline，但语义和使用场景不同。
例如，在定时任务中需要固定每天 23:59:59 取消操作，只能用 WithDeadline；而对一次 RPC 调用限制最多等 3 秒，用 WithTimeout 更自然、不易出错：
// ✅ 每日固定截止：必须用 WithDeadline dailyEnd := time.Date(year, month, day, 23, 59, 59, 0, loc) ctx, cancel := context.WithDeadline(parent, dailyEnd) <p>// ✅ 单次请求限时：WithTimeout 更安全（自动处理 now + dur） ctx, cancel := context.WithTimeout(parent, 3<em>time.Second) // 等价于 WithDeadline(parent, time.Now().Add(3</em>time.Second))
-
WithTimeout内部会调用WithDeadline，但多了一层时间计算，有微小开销（可忽略） - 若代码路径中存在明显延迟（如锁等待、GC STW），用
WithDeadline可能比WithTimeout更准——因为 deadline 是调用前就确定的，不受后续阻塞影响 - 调试时打印
deadline.String()比看 duration 更容易定位超时是否发生在预期时间点
子 context 的 deadline 不会自动继承父 context 的 deadline
Go 的 context 是单向链式结构，子 context 的 deadline 完全独立于父 context。即使父 context 有 deadline，用它创建子 context 时未显式指定 deadline，子 context 就没有 deadline。
典型陷阱：HTTP handler 中用带 deadline 的 req.Context() 启动 goroutine，但在 goroutine 内又调用 context.WithDeadline 却忘了把父 deadline 作为基准，导致子任务实际超时时间比预期长：
// ❌ 父 ctx 有 10s deadline，但子 ctx 设了 30s，整体可能拖到 30s 才结束
childCtx, _ := context.WithDeadline(ctx, time.Now().Add(30*time.Second))
<p>// ✅ 正确：取 min(父 deadline, 新 deadline)
if d, ok := ctx.Deadline(); ok {
deadline = d // 复用父 deadline，或取更早的那个
}
childCtx, _ := context.WithDeadline(ctx, deadline)
- 用
ctx.Deadline()获取父 context 的 deadline（返回(time.Time, bool)），仅当ok == true才有效 - 多个子任务共享同一 deadline 时，应统一从父 context 提取，而非各自调用
time.Now().Add(...)—— 避免因调用时间差导致 deadline 微小偏移 - 若父 context 没有 deadline，子 context 也不该擅自加一个，除非业务强要求；否则会破坏调用方的超时策略
Deadline 超时后，cancel() 函数仍需手动调用
context.WithDeadline 返回的 cancel 函数不只是释放资源，它还会关闭 ctx.Done() channel 并清空内部引用。即使 deadline 到期自动触发取消，cancel() 也**不是可选的**——漏掉会导致 context 泄漏。
最常见疏忽是只 defer cancel()，却在提前 return 前忘记调用它；或者在 select 中监听 ctx.Done() 后直接退出，没执行 cancel()：
// ❌ 危险：deadline 到期后 goroutine 退出，但 cancel 未调用
go func() {
select {
case <-ctx.Done():
// 忘了调用 cancel()
return
}
}()
<p>// ✅ 正确：无论何种退出路径，都确保 cancel 执行
defer cancel() // 在函数入口 defer 最稳妥
// 或者显式调用
select {
case <-ctx.Done():
cancel() // 显式清理
return
}
- 只要调用了
WithDeadline，就必须在生命周期结束时调用对应cancel()，哪怕已知 deadline 必然先触发 - 在 HTTP handler 中，通常在函数末尾
defer cancel()即可；但在 long-running goroutine 里，必须在所有退出分支上显式调用 - cancel 函数是幂等的，重复调用无副作用，所以不必担心“是否已取消”的判断逻辑
真正容易被忽略的是 deadline 的时区含义和系统时钟同步问题：传入的 time.Time 带时区，但 Go runtime 内部按纳秒计数，不校准时区；如果服务部署在不同时区的机器上，且 deadline 依赖本地日历（如“今天 24:00”），必须统一转成 UTC 时间再比较。
