不会。WithDeadline 不会立即取消，仅当系统时钟到达或超过 deadline 时才触发 cancel；它不终止 goroutine，需手动检查 ctx.Err() 退出。
context.WithDeadline 会立即触发取消吗？
不会。只要当前时间早于传入的 deadline，WithDeadline 就返回一个未取消的 Context；一旦系统时钟走到或超过该时间点，它才自动调用 cancel()。注意：这个判断基于系统时钟，不是运行时长。
常见错误是误以为“设置 5 秒后截止”等于“最多执行 5 秒”，但若程序启动时系统时间已漂移、或在容器中时钟不同步，就可能提前或延后取消。
- 务必用
time.Now().Add(5 * time.Second)计算 deadline，别硬写绝对时间 - 不要依赖本地时区——
time.Now()返回的是本地时间，而context内部用的是纳秒级单调时钟比较，实际影响不大，但写法要统一 - 测试时可用
time.AfterFunc模拟超时，避免真等 5 秒
WithDeadline 和 WithTimeout 有什么实质区别？
WithTimeout 是 WithDeadline 的封装：它内部就是把 time.Now().Add(timeout) 算出 deadline 后调用 WithDeadline。二者最终行为完全一致，底层都靠定时器触发 cancel。
选哪个只看语义清晰度：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 明确知道“从现在起最多跑 N 秒” → 用
WithTimeout，代码更直白 - 需要对齐某个外部时间点（如 HTTP 请求头里的
X-Deadline: 2024-06-15T14:30:00Z）→ 必须用WithDeadline，手动解析成time.Time - 两者返回的
Context类型、Done()行为、内存开销无差异
deadline 到了但 goroutine 还在跑，会自动终止吗？
不会。Go 没有抢占式取消机制。context 只是发信号，不杀协程。你必须主动检查 ctx.Err() 并退出逻辑。
典型漏检场景：
- 阻塞在
net.Conn.Read或http.Client.Do上：这些函数本身接受context.Context，会响应取消，但自定义 I/O（比如直接读os.File）不会 - 循环中没加
select或if ctx.Err() != nil判断 - 调用了不支持 context 的第三方库，且没做超时包装（例如老版本
database/sql驱动）
示例（正确响应）：
for {
select {
case <-ctx.Done():
return ctx.Err() // 退出循环
default:
// 执行单次任务
}
}为什么有时 deadline 没生效，ctx.Err() 一直是 nil？
最常见原因是：你忘了调用返回的 cancel 函数。虽然 WithDeadline 内部启了定时器，但若父 context 被提前取消，或你显式调了 cancel()，子 context 就会立刻结束——而如果一直不调 cancel，定时器会正常工作；但若父 context 已关闭，子 context 也会随之关闭，覆盖 deadline 逻辑。
- 总是用
defer cancel()，哪怕只是临时测试 - 检查父 context 是否已
Done()：如果parentCtx.Err() != nil，那WithDeadline返回的 context 一创建就是取消态 - 用
ctx.Deadline()确认是否真的设置了 deadline（返回(time.Time, bool)），避免传入零值time.Time{}
容易被忽略的一点：deadline 是单次触发的，不可重置。想重试并重设截止时间，必须新建 context。
