robfig/cron/v3 不适合高吞吐本地调度，因其单 goroutine 轮询导致阻塞、无超时限流重试；高性能方案应采用 time.Ticker + 缓冲 channel + 固定 worker pool 实现触发与执行解耦。
别用 robfig/cron/v3 做高吞吐本地分发——它单 goroutine 轮询，一卡全堵，延迟毛刺明显，且无超时、限流、重试等生产必需能力。 真正压得住每秒数千任务、延迟稳定在 0.8ms 级别的方案，是 time.Ticker + 带缓冲的 chan Task + 固定数量 worker pool。
为什么 robfig/cron/v3 不适合高性能本地调度
它本质是单 goroutine 每次 tick 都串行解析表达式 + 遍历所有注册任务 + 调用回调。每秒触发 1000 次时，CPU 就开始毛刺；一个任务执行慢（比如 200ms HTTP 请求），后面所有任务全被阻塞，完全不可控。
- 默认不启用秒级精度：
cron.New()解析"*/5 * * * * *"会被静默截成"* * * * *"，变成每分钟一次 - 所有任务共享同一个调度 goroutine，无法按类型限流（比如 CPU 密集型只跑 2 个，IO 型可跑 20 个）
- 没有内置上下文隔离、超时熔断、拒绝策略、失败告警或耗时统计——得自己 wrap 每个函数，重复代码多且易漏
- 引入 Redis 或外部 cron 库做本地调度，全是序列化、网络、锁争抢，纯属放大延迟
time.Ticker + chan Task + worker pool 实操要点
核心是把“触发”和“执行”彻底解耦：Ticker 只负责准时往 inbound chan Task 里扔任务，worker 从另一端消费。触发零延迟，执行完全异步可控。
使用 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 做唯一入口。
- worker 数量不是越多越好：实测 8 核机器上，
worker 数 = CPU 核数 × 1.5（即 12 个）时吞吐最高；再多反而因调度开销下降 - 加全局并发权重限制，用
golang.org/x/sync/semaphore：sem := semaphore.NewWeighted(100)，CPU 型任务加权 10，IO 型加权 1，实现细粒度资源配额 - 务必在服务 shutdown 时先 close
inbound，再waitgroup.Wait()，否则可能丢任务或 panic
容易被忽略的边界点
很多人以为只要 channel 缓冲够大、worker 数够多就稳了，其实最关键的三个隐性坑是：inbound 没做非阻塞写导致上游 panic、worker 内部没统一 context 超时、以及没对 len(inbound)/cap(inbound) 做实时告警。这三个点一旦漏掉，高负载下不是延迟飙升，就是 silently 丢任务。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
