用 time.Ticker + chan Task + 固定 worker pool 可支撑每秒数千定时任务、延迟低至0.8ms；robfig/cron/v3 因单 goroutine 轮询、无并发控制、无上下文隔离/超时/限流/重试等能力，不适用于高吞吐本地调度。
直接用 time.Ticker + chan Task + 固定 worker pool 就能撑住每秒数千定时任务，延迟压到 0.8ms 级别；别碰 Redis 或 cron 库做本地调度——它们引入的序列化、网络、锁争抢全是延迟放大器。
为什么不能用 robfig/cron/v3 做高吞吐本地分发
它本质是单 goroutine 轮询解析表达式 + 触发回调，每秒触发 1000 次时 CPU 毛刺明显，且不控制并发：你注册 10 个 AddFunc，每次 tick 都串行调用，一个慢任务卡住，后面全阻塞。更关键的是，它没提供任务上下文隔离、超时熔断、拒绝策略这些生产必需能力。
- 默认不启用秒级精度：
cron.New()解析"*/5 * * * * *"会被静默截成"* * * * *"，变成每分钟一次 - 所有任务共享同一个调度 goroutine，无法按权重限流（比如 CPU 密集型任务该只跑 2 个，IO 型可跑 20 个）
- 没有内置重试退避、失败告警、执行耗时统计——得自己 wrap 每个函数，重复代码多且易漏
用 time.Ticker 驱动 channel 分发的实操要点
核心是把“触发”和“执行”彻底解耦：Ticker 只负责准时往 inbound chan Task 里扔任务，worker 从另一端消费。这样触发逻辑零延迟，执行完全异步可控。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
inbound必须设缓冲：make(chan Task, 1024)，但绝不能无限大；满时用select { case inbound 主动拒绝，由上层决定降级（如写入 Redis 延迟队列） - Ticker 间隔必须大于等于任务平均耗时，否则
inbound持续积压；建议初始设为max(100*time.Millisecond, avg_exec_time*2) - 每个 worker 内部必须套
context.WithTimeout(ctx, task.Timeout)，超时自动 cancel，防止单任务 hang 住整个 goroutine - 监控
len(inbound)和cap(inbound)比值，超过 75% 就触发告警——说明消费者处理不过来，不是加大 buffer，而是调 worker 数或优化任务逻辑
如何防 goroutine 泛滥和 channel 阻塞雪崩
常见错误是 go task.Run() 每次都启新 goroutine，QPS 陡增时瞬间上万 goroutine，调度器过载、内存暴涨。真正可控的做法是固定数量长期运行的 worker，用 channel 做唯一入口。
立即学习“go语言免费学习笔记（深入）”；
- worker 数量不是越多越好：实测 8 核机器上，worker 数 = CPU 核数 × 1.5（即 12 个）时吞吐最高；再多反而因调度开销下降
- 加全局并发权重限制，用
golang.org/x/sync/semaphore：sem := semaphore.NewWeighted(100)，CPU 型任务Acquire(ctx, 5)，IO 型Acquire(ctx, 1)，比单纯数 goroutine 准确得多 - 禁止在
inbound的 send 侧用无缓冲 channel：一旦 worker 全忙，inbound 会直接阻塞 HTTP handler，导致整个请求 goroutine 挂起 - 所有任务结构体必须预分配字段，避免 runtime.alloc；实测任务 struct 大小控制在 128 字节内，GC 压力明显降低
真正难的不是写通逻辑，而是把 inbound 容量、worker 数量、semaphore 权重、timeout 时间这四个参数调到恰到好处——它们互相牵制，改一个就得压测另三个。线上环境永远以 len(inbound)/cap(inbound) 和 runtime.NumGoroutine() 为第一监控指标，而不是看 QPS 数字。
