time.Ticker不能作通用周期调度器，因其每个实例独占goroutine+channel+timer节点，10,000个即10,000个活跃goroutine，导致内存线性暴涨、GC压力剧增；适用场景仅限服务级心跳、全局指标采集等少数固定节奏任务。
time.Ticker 和 time.Timer 不是“语言学习思路”的产物，而是标准库中为特定语义设计的原语。优化大规模定时器性能的关键，不是套用学习方法论，而是认清每个类型的真实开销、适用边界和替代路径。
为什么不能把 time.Ticker 当“通用周期调度器”用
每个 time.NewTicker 实例背后是一个独立 goroutine + channel + runtime.timer 节点。10,000 个 ticker ≈ 10,000 个活跃 goroutine，内存占用线性上涨，GC 压力陡增。这不是写法问题，是设计契约：它只承诺“全局统一节奏”，不承诺“低开销千频并发”。
- 常见错误现象：
runtime: out of memory、pprof 显示大量runtime.timer占 heap、NumGoroutine稳定在数万级 - 适用场景：服务级心跳广播、全局指标采集等少数几个固定节奏任务
- 误用典型：为每个 TCP 连接/每个 WebSocket 客户端/每个租户单独启一个
time.Ticker
time.After 在循环里等于定时器爆炸
time.After 是 time.NewTimer 的封装，返回 channel 后不暴露 Stop() 接口。在 for 循环中直接使用，等于每轮都新建 timer 并永久泄漏其 runtime 结构体。
- 错误写法：
for { select { case - 正确替代：复用单个
*time.Timer，用Reset()重设；或改用time.Ticker（注意 channel 缓冲为 1，handler 执行超时会丢 tick） - 更轻量方案：若只是“延迟后执行一次”且不依赖精确唤醒，可用
time.Sleep+ 新 goroutine —— 它走系统调用，不进 runtime timer 堆，无锁无分配
时间轮（TimeWheel）才是万级任务的正解
时间轮把时间切片成槽位（如每槽 100ms），任务按剩余延迟归入对应 slot；后台指针匀速扫槽，到即触发。添加/删除/触发均为 O(1)，内存占用与任务数几乎无关。
立即学习“go语言免费学习笔记（深入）”；
- 推荐实现：
github.com/RichardKnop/machinery/v2或轻量自研timewheel；避免直接用hashicorp/go-timerwheel默认配置 —— 它的tick和size必须按最大容忍延迟反推（如允许 ±200ms 偏差，则tick = 100 * time.Millisecond，size = 64） - 必须显式调用
.Stop()：TimerWheel.ScheduleFunc()返回的*timerwheel.Timer不.Stop()，底层 slot 槽位不会释放，长期运行后内存只增不减 - 回调里禁止阻塞：时间轮调度线程是单 goroutine，HTTP 调用或 DB 查询会卡住整个轮子；应启动新 goroutine 处理
调试时怎么确认时间轮真正在省内存
不能只看 RSS，得看 runtime 底层指标和分配模式。
- 用
runtime.ReadMemStats对比：重点关注Mallocs（每秒新分配对象数）和NumGoroutine—— 正常应稳定在个位数，而非随定时器数量增长 - pprof 查
go tool pprof http://localhost:6060/debug/pprof/heap，过滤timerwheel，确认无持续增长的结构体实例 - 真正容易被忽略的是：所有定时器对象必须复用 —— 用
sync.Pool管理timerEntry，禁止每次new；停止逻辑要穿透多层（如两级轮），否则残留任务会在某次 tick 后诡异触发
