会，time.ticker 会漏掉 tick；因其 channel 无缓冲，若 for range 循环中执行耗时操作（如 http 请求、db 写入），未及时读取则新 tick 被丢弃，故应避免在循环内阻塞或使用 select+default/超时处理。
time.Ticker 会漏掉 tick 吗？
会，而且很常见。当你在 for range ticker.C 循环里做耗时操作（比如 HTTP 请求、数据库写入、文件读写），下一次 tick 到来时，如果上一轮还没处理完，这个 tick 就直接被丢弃——ticker.C 是一个无缓冲 channel，发不进去就丢。
- 别在
for循环里直接塞重逻辑，尤其别阻塞在select外面 - 用
select+default或带超时的case 主动控制节奏 - 真要保序且不能丢任务？改用
time.AfterFunc链式调用，或自己维护一个 worker pool
为什么 time.NewTicker(1 * time.Second) 实际间隔远大于 1 秒？
不是 ticker 慢了，是你的处理逻辑拖慢了整个循环节奏。Golang 的 time.Ticker 只负责“按固定时间往 channel 里塞值”，它不保证你“能及时取到”。一旦你取值后花 800ms 处理，那下次取到的时间就是 1.8 秒后。
- 观察
time.Since(lastRun)而不是依赖 “每秒一次” 的直觉 - 避免在
case 后立刻执行耗时函数；拆成“触发信号”和“异步执行”两步 - 调试时加日志：
log.Printf("tick at %v, last run was %v ago", time.Now(), time.Since(lastRun))
需要精确到毫秒级调度，还能用 Ticker 吗？
能，但别指望靠增加频率解决精度问题。频繁创建/停止 time.Ticker（比如每次动态改间隔）反而引发 goroutine 泄漏和时间漂移。真正影响精度的是 GC 停顿、系统调度延迟、以及你代码里隐藏的同步等待（比如锁、channel 阻塞）。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
time.Ticker本身底层调用runtime.timer，在大多数 Linux 环境下可稳定做到 ±1–2ms 误差 - 不要用
time.Sleep替代Ticker做周期控制——它无法应对系统时间跳变，且误差累积快 - 若需 sub-ms 精度（如音频同步、高频采样），得换 OS-level timer（如
timerfd_create）或专用库，Go 标准库不支持
程序退出时 ticker 忘记 Stop，会泄露 goroutine 吗？
会。每个 time.NewTicker 都启动一个后台 goroutine 维护定时器，不调 ticker.Stop()，它就一直活着，哪怕主逻辑早已结束。pprof 查 runtime/pprof/goroutine 常能看到一堆 time.go:... timerproc。
- 务必在 defer 或 shutdown hook 里调
ticker.Stop() - 别把
ticker声明成包级变量——容易被多处误用、难清理 - 用 context 控制生命周期更稳妥：
func startTicker(ctx context.Context, d time.Duration) { ... select { case
实际写的时候，最常被忽略的是：ticker 不是“执行器”，只是“发令枪”。你怎么接招，决定了它准不准、稳不稳、会不会咬住你不放。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
