超时控制必须复用 time.after 通道并配合 context.context 实现真取消，否则会因重复创建计时器导致超时失效或 goroutine 泄漏。
Go 里用通道做任务分发时，超时控制不是加个 time.After 就完事——它必须和 select 配合、只创建一次、且不能替代任务取消。否则要么超时失效，要么 goroutine 泄漏。
为什么 time.After 放在循环里就失效
常见写法是每个任务都调 time.After(1 * time.Second)，然后塞进 select。但每次调用都会新建一个独立的计时器通道，相当于每次都在重置倒计时。哪怕总耗时 10 秒，只要每个任务单独在 1 秒内完成（或陆续完成），就不会触发超时分支。
-
time.After返回的是新通道，生命周期仅限当前select块 - goroutine 仍在后台跑，
select超时只是放弃等待，不终止执行 - 若任务函数无主动退出逻辑，会持续占用资源
正确构造带超时的任务分发器
核心是把超时通道抽出来，复用一次；同时用 context.Context 实现真取消，而不是只等结果。
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 用
context.WithTimeout创建可取消上下文，传给每个 worker - worker 函数内部检查
ctx.Done()并提前返回 - 主 goroutine 的
select只监听一次timeoutChan，而非每个任务都配一个 - 结果通道建议用带缓冲的
make(chan Result, len(tasks))，避免发送阻塞影响超时判断
timeoutChan := time.After(5 * time.Second)
for i := range tasks {
go func(i int) {
result := doWork(ctx, tasks[i]) // ctx 来自 WithTimeout
select {
case results <h3>并发任务分发中容易被忽略的 channel 状态细节</h3><p>通道关闭、nil、满/空这些状态直接影响超时逻辑是否生效，但很多人只关注“有没有数据”，不检查“为什么没数据”。</p>
- 向已关闭的 channel 发送会 panic：
send on closed channel - 从已关闭且为空的 channel 接收，会立即返回零值 +
ok=false，不是阻塞 - channel 设为
nil后，select中对应 case 会被忽略，但不会报错——这常被误用作“禁用通道” - 无缓冲 channel 必须收发双方同时就绪，否则死锁；超时逻辑必须覆盖所有可能阻塞路径
学习并发模式时最该盯住的三个实操点
别光看 runner、worker pool 这类名词，真正卡住人的永远是通道生命周期、goroutine 退出条件、以及超时与取消的边界。
- 每个 goroutine 必须有明确退出路径：靠
ctx.Done()、靠 channel 关闭、或靠显式 break - 超时通道和结果通道不能共用同一个
select分支——它们语义不同，混用会导致逻辑混乱 - 测试时一定要模拟慢任务（比如
time.Sleep(10 * time.Second)），验证超时是否真起作用、goroutine 是否真退出
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
