直接用 map 存储耗时分布会出错，因为 Go 中 map 非并发安全，多 goroutine 同时写入（如 HTTP handler、中间件、指标上报）将触发 fatal error: concurrent map writes；须用 sync.RWMutex 或 sync.Map 保护，且应预定义 bucket key、避免运行时拼接字符串和存储原始 time.Duration。
为什么直接用 map 存储耗时分布会出错？
Go 语言中 map 本身不是并发安全的，而异步日志采样场景下，多个 goroutine（如 HTTP handler、中间件、指标上报协程）会同时写入同一份耗时统计 map。不加保护直接操作会导致 fatal error: concurrent map writes —— 这是最常见的崩溃点。
常见错误写法：
latencyMap := make(map[string]int64) // key: "200-50ms", value: count // 多个 goroutine 同时执行： latencyMap[key]++ // panic！
- 必须用
sync.RWMutex或sync.Map替代原生map，但注意sync.Map不适合高频迭代（比如每秒汇总导出） - 若需按区间聚合（如 0–10ms、10–50ms），建议预定义 bucket keys，避免运行时拼接字符串引发 GC 压力
- 不要在
map中存原始耗时值（time.Duration），而是归一化为 bucket key 字符串或整数索引
如何设计低开销的耗时 bucket key？
关键不是“分得越细越好”，而是让 key 生成快、可预测、利于后续聚合。例如把 137ms 映射为 "100-200ms"，比用浮点除法或 fmt.Sprintf 更轻量。
推荐做法：
func latencyBucket(d time.Duration) string {
ms := d.Milliseconds()
switch {
case ms < 1: return "0-1ms"
case ms < 10: return "1-10ms"
case ms < 50: return "10-50ms"
case ms < 200: return "50-200ms"
case ms < 1000: return "200-1000ms"
default: return "1000ms+"
}
}
- 用
switch替代 slice 二分查找，避免内存分配和边界计算开销 - 避免在 hot path（如每个请求入口）调用
fmt.Sprintf或strconv—— 它们会触发堆分配 - 如果 bucket 数量固定且不多（≤10），可改用整数索引（
uint8）代替字符串 key，后续用数组存 count，性能更高
异步采样：什么时候该丢弃日志，而不是全量上报？
不是所有慢请求都值得记录。盲目打点会导致日志爆炸、存储成本飙升，反而掩盖真实问题。采样逻辑必须和 bucket 绑定，而非全局固定比率。
- 对高频低耗时 bucket（如
"1-10ms"），采样率设为0.1%；对低频高耗时 bucket（如"1000ms+"），设为100% - 用
hash/fnv对请求标识（如 traceID 或 URI+method）做轻量哈希，再对 bucket 的采样分母取模，保证同 bucket 下采样均匀且可复现 - 切忌用
rand.Float64()—— 全局随机数生成器有锁，且无法跨进程/重启复现采样行为 - 采样决策必须在耗时测量完成**后立即执行**，避免在 defer 或异步 goroutine 中判断 —— 此时上下文可能已销毁
监控策略落地：如何从 map 数据生成 Prometheus 指标？
直接暴露 map 内容给 Prometheus 不可行。需要将 bucket key 转为 label，并通过 prometheus.NewHistogramVec 管理。
正确姿势：
histogram := prometheus.NewHistogramVec(
prometheus.HistogramOpts{
Name: "http_request_duration_ms",
Help: "Latency distribution of HTTP requests",
Buckets: []float64{1, 10, 50, 200, 1000}, // 与 bucket key 对齐
},
[]string{"status_code", "method"},
)
- 不要试图把自定义 bucket key（如
"50-200ms"）作为 label 值塞进 Histogram —— 这破坏直方图语义，导致rate()、histogram_quantile()失效 - 如果已有基于
map的 bucket 计数，可用prometheus.NewCounterVec+ 静态 label（如le="1000"）模拟，但需手动维护 label 组合 - 定期（如每 10 秒）将
map中的计数原子清零并转为Observe()调用，避免长尾延迟 skew 指标
最易被忽略的一点：bucket 边界必须严格匹配监控查询习惯。比如 SRE 习惯看 P95，那就不能只保留 “200-1000ms” 这种宽泛区间 —— 得拆到 100ms 级别，否则 quantile 计算全是估算。
