context.WithTimeout 返回 timerCtx，其 Done() 是无缓冲 channel，这是为保证取消信号及时、确定地通知所有监听者，并维持各 context 类型语义一致。
没有“带缓冲超时的 Context”这种东西——context.WithTimeout 返回的是 timerCtx，它的 Done() 是一个无缓冲 channel，你不能也不该给它加缓冲。
为什么 ctx.Done() 一定是无缓冲 channel
Go 的 context 包内部实现中，timerCtx（由 context.WithTimeout 创建）的 done 字段是 chan struct{} 类型，且明确不带缓冲。这是有意设计：
- 缓冲 channel 会延迟通知：如果
done是make(chan struct{}, 1)，第一次取消信号会被缓存，但后续 goroutine 若未及时读取，可能错过第二次取消（虽然实际不会发生，因为 cancel 只触发一次）；更关键的是，这破坏了 “select等待Done()就是等待确切取消点” 的语义一致性 - 所有 context 类型（
cancelCtx、timerCtx、valueCtx）的Done()都返回同一类型 channel，统一为无缓冲，是为了让下游代码无需关心上游用的是 WithCancel 还是 WithTimeout - 标准库中所有基于
ctx.Done()的阻塞逻辑（如http.Transport、database/sql）都依赖它“关闭即就绪”的行为，加缓冲会导致不可预测的竞态或延迟响应
你真正需要的可能是这三种场景之一
所谓“带缓冲超时”，往往反映的是对并发控制或信号消费方式的误解。常见真实需求和对应解法：
-
多个 goroutine 同时监听同一个超时 context，但不想因争抢
Done()而漏信号：不用改 channel 缓冲，直接把同一个ctx传给所有 goroutine。每个 goroutine 自己调，channel 关闭后所有监听者都会立即收到（无竞争、无丢失） -
想在超时后仍能“重试一次”或“降级处理”，而不是立刻退出：这不是缓冲问题，而是控制流设计。用
select+time.After组合，例如：select { case <-ctx.Done(): return ctx.Err() case <-time.After(100 * time.Millisecond): // 降级逻辑 } -
需要“超时但允许宽限期继续完成当前操作”：这不是 context 能解决的，context 只负责发信号。你应该在收到
ctx.Done()后启动清理计时器，比如：go func() { <-ctx.Done() // 启动 500ms 宽限期，之后强制终止 select { case <-time.After(500 * time.Millisecond): forceStop() } }()
context.WithTimeout 的正确用法和易错点
直接用就行，但必须注意三件事：
立即学习“go语言免费学习笔记（深入）”；
- 一定要调用
cancel函数，哪怕超时已触发——否则底层 timer 不释放，长期运行服务会内存泄漏。写法固定：ctx, cancel := context.WithTimeout(parent, 3*time.Second) defer cancel() // 即使超时了也要 defer
- 不要把
ctx存到结构体字段里长期持有，除非你明确管理其生命周期。它是一次性请求上下文，不是全局配置 -
context.WithTimeout的第二个参数是time.Duration，不是时间点。要设截止时间请用context.WithDeadline，别用time.Now().Add(...)手算，容易出错
真正复杂的地方在于：超时只是信号起点，怎么响应它——是否中断 I/O、是否释放锁、是否回滚事务、是否记录 trace——这些逻辑不在 context 里，而在于你收到 后那一小段代码。这里最容易被忽略的是资源清理的完整性，而不是 channel 有没有缓冲。
