time.ticker 无法做到高精度触发。它受 go 调度、gc 和系统调用影响，10ms 周期偏差达 2–8ms；5ms 及以下不可控；适合粗粒度周期任务，不适用于硬实时场景；其无缓冲 channel 特性导致 tick 丢失，需校准时间或换用 timerfd 等方案。
time.ticker 能不能做到高精度触发？
不能。go 标准库的 time.ticker 无法保证毫秒级（尤其是 ≤10ms）的稳定精度，实测在 10ms 周期下，单次偏差常达 2–8ms；5ms 及以下基本不可控。这不是 bug，而是受 go 运行时调度、gc 暂停、系统调用延迟共同影响的结果。
它适合「大致均匀」的周期任务，比如每 100ms 采集指标、每 5s 上报心跳；不适合硬实时场景，如音频同步、高频信号生成、精确 PWM 控制。
常见错误现象：fmt.Println("tick") 打印的时间戳显示间隔忽大忽小，甚至跳过一次 —— 这通常不是 ticker 本身坏了，而是你的 doWork() 阻塞太久，或 GC 正在运行。
为什么 ticker.C 会丢 tick？
time.Ticker.C 是一个无缓冲 channel。每次到点就尝试发送当前时间，但若上一轮还没从 channel 里读出来，新 tick 就直接被丢弃。
这在以下情况极易发生：
- 你在
for range ticker.C循环体内直接执行耗时操作（如 HTTP 请求、DB 写入、文件读写） - 任务执行时间 > tick 间隔（例如 800ms 任务配 1s ticker），导致下个 tick 到来前 channel 仍空不下来
- 没加互斥控制，多个 goroutine 并发读取同一
ticker.C，引发竞争或 panic
别指望靠增加频率“弥补丢失”——频繁创建/停止 time.Ticker 反而引发 goroutine 泄漏和时间漂移。
如何让周期任务更稳一点？
核心思路是：不用固定 Sleep，改用时间校准。每次任务结束后，计算「本该在何时开始下一次」，再 time.Sleep 到那个时刻，而不是简单 Sleep 固定时长。
示例（目标 10ms 周期）：
next := time.Now().Add(10 * time.Millisecond)
for range ticker.C {
doWork()
sleepDur := time.Until(next)
if sleepDur > 0 {
time.Sleep(sleepDur)
}
next = next.Add(10 * time.Millisecond)
}
这个做法比纯 time.Ticker 更可控，实测抖动能压到 ±0.3ms 内（前提：doWork() 执行时间 ≤2ms，且无长时间阻塞）。
注意：time.Until() 返回负值表示已超时，此时跳过 Sleep，直接进入下一轮，否则会 panic。
真正需要 sub-ms 精度时该怎么办？
Go 标准库不支持亚毫秒级定时。想逼近硬件精度，得换方案：
- Linux 下可用
timerfd_create+epoll，绕过 Go runtime 直接对接内核高精度定时器 - 用专用库如
posener/timer（基于timerfd封装） - 对精度要求极端严格的场景（如金融交易），应交由 C/C++ 或 Rust 编写的底层模块处理，Go 仅做协调
别用 runtime.LockOSThread 强绑线程——Go 运行时禁止 locked thread 中调用多数阻塞系统调用，容易触发 fatal error: all goroutines are asleep，还会影响 GC 安全性。
最常被忽略的一点：无论用哪种方式，只要任务逻辑里有锁、channel 阻塞、或未设 timeout 的 I/O，精度就会立刻崩掉。精度不在 ticker 里，而在你代码的每一行执行路径上。
