在Go语言的服务开发里，定时器和耗时统计往往是两个被分开讨论的话题。实际上标准库中的time.Timer以及time.Time组合使用，可以非常方便地完成一次查询或者一段逻辑的真实耗时记录。很多性能问题并不是出现在主流程，而是隐藏在不起眼的定时回调或者周期任务中，这时候用timer开启查询耗时统计就成为一种低成本、高收益的排查手段。
利用time.Timer与time.Now实现基础耗时统计
最直观的做法是在查询逻辑开始前记录起始时间，在逻辑结束后计算时间差。Go的time.Now返回当前时间，配合Sub方法就能拿到time.Duration。虽然time.Timer本身用于未来的单次触发，但我们可以借助它来做超时控制和耗时上限告警，从而形成一套完整的统计方案。
下面示例展示了一个简单的统计函数，它在执行查询前启动一个timer用于超时熔断，同时记录开始时间，查询结束后再停止timer并输出耗时：
package main
import (
"fmt"
"time"
)
func queryWithStat(timeout time.Duration) {
start := time.Now()
// 开启一个timer用于超时控制
t := time.NewTimer(timeout)
defer t.Stop()
done := make(chan string, 1)
go func() {
// 模拟查询耗时
time.Sleep(120 * time.Millisecond)
done <- "result"
}()
select {
case res := <-done:
elapsed := time.Since(start)
fmt.Printf("查询完成，结果：%s，耗时：%vn", res, elapsed)
case <-t.C:
elapsed := time.Since(start)
fmt.Printf("查询超时，已耗费：%vn", elapsed)
}
}
func main() {
queryWithStat(200 * time.Millisecond)
}
上面的代码里，time.Since(start)等价于time.Now().Sub(start)，能够直接给出从开始到当前的时间间隔。我们把timer的超时时间和统计耗时放在一起，既知道有没有超时，也知道实际花了多少时间。这种方式比在日志里打印时间戳要清晰得多，也更容易做结构化输出。
需要注意的是，time.NewTimer创建的timer在不再需要时应当调用Stop方法，否则底层runtime仍会持有该timer直到触发。在高频查询统计场景中，忘记Stop会造成不必要的对象驻留，反而影响性能。因此用defer t.Stop()是一种稳妥的写法。
在高频查询中避免统计误差与资源浪费
当查询每秒触发成千上万次时，每次都新建timer和channel会带来明显的分配开销。此时更好的策略是复用对象，或者仅在需要超时保护时才启用timer，而耗时统计只用time.Now。我们可以把纯粹的统计和超时控制解耦：耗时统计永远轻量，timer只用于真正危险的外部调用。
下面的例子演示了一个解耦后的统计封装，普通内部查询只统计耗时，外部依赖才附带timer超时：
package main
import (
"fmt"
"time"
)
type Stat struct {
start time.Time
}
func BeginStat() Stat {
return Stat{start: time.Now()}
}
func (s Stat) End(label string) {
elapsed := time.Since(s.start)
fmt.Printf("[%s] 耗时：%vn", label, elapsed)
}
func internalQuery() {
s := BeginStat()
// 模拟内部计算
time.Sleep(5 * time.Millisecond)
s.End("internal")
}
func externalQuery() {
s := BeginStat()
t := time.NewTimer(50 * time.Millisecond)
defer t.Stop()
// 模拟慢调用
time.Sleep(80 * time.Millisecond)
<-t.C
s.End("external")
}
func main() {
for i := 0; i < 3; i++ {
internalQuery()
}
externalQuery()
}
从代码可以看出，internalQuery完全没有创建timer，只用了BeginStat和End来输出耗时，这对于高频路径非常友好。而externalQuery由于可能阻塞过久，保留了timer做超时示意。实际项目中你可以根据调用类型自由选择，避免所有路径都背上timer的额外成本。
另一个常见误差来源是时钟精度和系统调度抖动。在Linux上time.Now通常基于单调时钟，精度足够微秒级，但如果把统计结果直接当作绝对性能基线，需要排除GC停顿和调度延迟。建议在生产环境连续采样多次取中位数，而不是看单次最大值，否则容易被偶发抖动误导。
将timer耗时统计接入监控与日志体系
单纯打印到控制台并不能持久化分析，真正落地要把统计数值送到监控系统。我们可以定义一个全局的统计收集器，在End方法里不仅打印，还把耗时记录到Prometheus指标或者自定义计数器中。timer依然负责超时边界，统计结构负责采集数据。
以下示例展示如何把耗时写入一个简单的内存聚合结构，并区分是否触发了timer超时：
package main
import (
"fmt"
"sync"
"time"
)
type Metrics struct {
mu sync.Mutex
total time.Duration
timeouts int
count int
}
func (m *Metrics) Record(elapsed time.Duration, timeout bool) {
m.mu.Lock()
defer m.mu.Unlock()
m.total += elapsed
m.count++
if timeout {
m.timeouts++
}
}
func (m *Metrics) Show() {
m.mu.Lock()
defer m.mu.Unlock()
if m.count == 0 {
return
}
avg := m.total / time.Duration(m.count)
fmt.Printf("平均耗时：%v，超时次数：%d，样本数：%dn", avg, m.timeouts, m.count)
}
var globalMetrics = &Metrics{}
func queryWithMetrics(timeout time.Duration) {
start := time.Now()
t := time.NewTimer(timeout)
defer t.Stop()
done := make(chan struct{})
go func() {
time.Sleep(60 * time.Millisecond)
close(done)
}()
select {
case <-done:
globalMetrics.Record(time.Since(start), false)
case <-t.C:
globalMetrics.Record(time.Since(start), true)
}
}
func main() {
for i := 0; i < 5; i++ {
queryWithMetrics(50 * time.Millisecond)
}
globalMetrics.Show()
}
在这段实现中，Metrics用互斥锁保护累加过程，使得多个goroutine并发统计也安全。每次查询结束都调用Record，把耗时和是否超时传进去。这样我们既能从聚合数据看到平均响应，也能知道timer超时发生的频率，对容量规划很有帮助。
如果团队已经使用Prometheus，可以把Record内部换成Histogram或者Counter的Observe与Inc调用，timer的统计值直接作为观测值。日志方面建议采用结构化字段，例如elapsed_ms和timer_timeout，方便后续用ELK或者Loki做筛选。整体思路就是让timer既做护栏又做标尺，统计逻辑保持轻量，监控闭环自然形成。