用 net.interfacestat 获取实时网卡流量需轮询采样 bytessent/bytesrecv 累计值，两次差值除以时间得速率；应使用 time.ticker 而非 time.sleep 避免漂移；注意容器内统计不准，需宿主机采样物理或桥接网卡。
如何用 net.InterfaceStat 获取实时网卡流量
Go 标准库不提供开箱即用的“带宽监控”抽象，得自己轮询网卡统计。核心是 net.Interfaces() 配合每个接口的 Interface.Stat() 方法，它返回 *net.InterfaceStat，里面有 BytesSent 和 BytesRecv 字段。
注意：这些值是自系统启动以来的累计字节数，不是瞬时速率。要算带宽（如 Mbps），必须做两次采样、求差、除以时间间隔。
- 别直接用
time.Now().UnixNano()做间隔——纳秒级精度没意义，且可能因系统时钟跳变导致负值；用time.Since()更稳妥 - Linux 下某些虚拟网卡（如
veth、docker0）会统计容器间流量，但宿主机物理网卡（如eth0）才反映真实出向带宽 - Windows 上部分驱动不支持精确统计，
BytesRecv可能长期为 0；建议加 fallback 判断：if stat.BytesRecv == 0 && len(interfaces) > 1就跳过该接口
iface, _ := net.InterfaceByName("eth0")
stat, _ := iface.Stat()
fmt.Printf("total recv: %d B\n", stat.BytesRecv)
time.Ticker 轮询时为什么不能只 sleep 固定 1 秒
用 time.Sleep(1 * time.Second) 做循环间隔，会导致采样漂移：每次统计+打印本身耗时（哪怕几毫秒），累积下来，实际间隔越来越长，算出来的带宽越来越低。
正确做法是用 time.Ticker，它基于系统时钟节拍驱动，误差可控在毫秒级内。
立即学习“go语言免费学习笔记（深入）”；
- 别在 ticker 循环里做阻塞操作（如写磁盘、HTTP 请求），否则会拖慢下一次触发
- 如果需要每 5 秒统计一次，就用
time.NewTicker(5 * time.Second)，不要手动 sleep 5 秒再加误差补偿 - 务必在程序退出前调用
ticker.Stop()，否则 goroutine 泄漏
实现流量计费器的关键逻辑：怎么把字节换算成费用
计费不是简单乘单价。真实场景要考虑阶梯价、包年包月抵扣、免流白名单、精度截断等。最简版本也得区分上下行、按自然日重置、支持小数点后两位计费。
- 别用
float64存费用——浮点误差会导致 0.1 + 0.2 ≠ 0.3；统一转成「分」用int64运算，最后除 100 输出 - 计费周期必须用 UTC 时间判断，避免本地时区夏令时切换导致重复或跳过结算
- 白名单 IP 或域名需在流量采样阶段就过滤，而不是等计费时再查——否则已计入的流量无法回退
- 示例：上行 1MB 按 0.05 元/MB，则费用 =
(bytesSent / 1024 / 1024) * 5（单位为分）
为什么 net.InterfaceStat 在容器里经常不准
在 Docker 或 Kubernetes 中，net.InterfaceStat() 默认读的是容器网络命名空间里的接口（如 eth0），但这个 eth0 实际是 veth pair 的一端，统计的是容器到宿主机的内部流量，不是最终出公网的量。
真正要监控对外带宽，得在宿主机上查对应 veth 的 peer（通常是 vethe123abc）或直接读 docker0、cbr0 等桥接网卡。
- 容器内执行
cat /sys/class/net/eth0/nameif可能为空，说明没有绑定 host 接口名，此时InterfaceStat返回的只是 dummy 统计 - K8s Pod 中更推荐用 cAdvisor 或 eBPF 方案（如 Cilium 的 metrics），标准库方案在这里基本不可靠
- 若必须用 Go 做，容器启动时通过
hostNetwork: true或挂载/sys/class/net到容器内，再读宿主机网卡
带宽监控真正的复杂点不在采集，而在边界定义：你到底想监控哪一层的“带宽”——TCP 层？IP 层？物理网卡？容器网络？选错层，后面所有计费逻辑都偏了。
