应使用两次 net.InterfaceStat 采样差值除以 time.Since(lastTime) 计算真实带宽，配合 time.Ticker 定时、Gauge 指标暴露、整数计费与 UTC 结算，确保速率稳定、标签可聚合、费用可审计。
用 net.InterfaceStat 做采样，但别直接差值除时间
真实带宽不是“当前字节数 − 上次字节数”，而是单位时间内的增量速率。net.InterfaceStat 返回的 BytesRecv 和 BytesSent 是自系统启动以来的累计值，必须做两次采样、求差、再除以真实经过的时间。
常见错误是写成：delta := now.BytesRecv - last.BytesRecv; bps := delta / 1000000 —— 这里除的是固定秒数（比如 1），但实际采样间隔可能因 GC、调度延迟或阻塞操作而漂移，导致结果偏低甚至为负。
- 用
time.Since(lastTime)替代硬编码时间间隔，避免时钟跳变或累积误差 - 容器内采集要小心：Docker 的
veth*或docker0接口统计的是容器间流量，真正出向带宽应查宿主机的物理网卡（如eth0或ens33） - Windows 下部分驱动不返回有效值，
BytesRecv可能恒为 0；建议加 fallback 判断：if stat.BytesRecv == 0 && len(ifaces) > 1就跳过该接口
用 time.Ticker 控制节奏，别用 time.Sleep
time.Sleep(1 * time.Second) 看似简单，但每次循环中统计、计算、日志打印等操作本身耗时（哪怕几毫秒），多次叠加后，实际间隔会越来越长，带宽值持续失真。
time.Ticker 是基于系统时钟节拍的定时器，误差可控在毫秒级，更适合周期性监控场景。
立即学习“go语言免费学习笔记（深入）”；
- 初始化：
ticker := time.NewTicker(5 * time.Second)，表示每 5 秒触发一次 - 务必在程序退出前调用
ticker.Stop()，否则 goroutine 泄漏 - 不要在 ticker 循环里做阻塞操作（如同步写磁盘、HTTP 请求、未加超时的数据库查询），否则下一次 tick 会被推迟
- 如果需要按自然分钟对齐（比如每分钟整点上报），可用
time.Truncate对齐起始时间，而非依赖 ticker 自身精度
指标类型选 Gauge，别用 Counter 记带宽
带宽是瞬时速率（如 Mbps），属于“此刻是多少”的值，不是“累计发生多少次”。Prometheus 中对应的是 Gauge 类型，可增可减、支持重置，适合暴露实时速率。
误用 Counter 会导致两个问题：一是 Counter 只能单调递增，无法表达带宽波动；二是 Prometheus 抓取时会对 Counter 做 rate() 计算，而你已经算好了速率，再套一层 rate() 就完全错乱。
- 注册方式示例：
bandwidthIn := prometheus.NewGauge(prometheus.GaugeOpts{Name: "network_bytes_in_per_second", Help: "Incoming bandwidth in bytes/sec"}) - 更新时直接
bandwidthIn.Set(float64(deltaRecv) / elapsed.Seconds())，无需.Inc()或.Add() - 如果同时暴露上下行，建议用 label 区分：
bandwidth{direction="in"}和bandwidth{direction="out"}，比定义两个独立指标更易聚合
计费逻辑必须用整数运算，别碰 float64
一旦涉及金额，float64 的精度误差就会暴露——比如 0.1 + 0.2 != 0.3，线上计费系统出错不可接受。
最简可靠做法是全程用 int64 表示“最小货币单位”（如“分”），所有乘除都在整数域完成，最后才转成小数展示。
- 上行 1MB 按 0.05 元/MB 计费，应写成：
feeCents := (bytesSent / 1024 / 1024) * 5 - 结算周期必须用 UTC 时间判断，避免本地时区夏令时切换导致某天被跳过或重复计费
- 白名单过滤必须前置：在采样阶段就根据 IP 或端口丢弃流量，而不是等计费时再筛——已计入的字节数无法回退
流量监控模块真正的复杂点不在采集，而在“怎么让速率稳定、标签可聚合、费用可审计”。这三个环节任一松动，都会让后续告警、计费、容量规划失去可信基础。
