Linux下最可靠方式是直接解析/proc/net/dev，跳过前两列后第1列rx_bytes、第9列tx_bytes；Windows应优先用GetIfEntry2()配合ConvertInterfaceIndexToLuid()，避免32位溢出；跨平台需后台线程定时采样并用steady_clock计时。
Linux下读取/proc/net/dev获取实时网速最可靠
直接解析/proc/net/dev是C++在Linux上获取网络收发速率最轻量、最稳定的方式。它不依赖第三方库，无权限问题，且内核保证数据一致性。注意：该文件每行代表一个网络接口，首行为字段头，第二行起才是真实数据；字段顺序固定，但不同内核版本列数可能不同（如是否含压缩/错误包计数），需跳过前两列（接口名和冒号）后，第1列是接收字节数rx_bytes，第9列是发送字节数tx_bytes。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
std::ifstream按行读取，跳过空行和注释行（以#开头） - 对目标接口（如
"eth0"或"wlan0"）做精确字符串匹配，避免子串误匹配（如"eth0"vs"eth0:1"） - 两次采样间隔建议≥100ms，太短会导致浮点除零或精度失真
- 注意
unsigned long long类型——32位系统下/proc/net/dev的字节数可能超unsigned long范围
Windows用GetIfEntry2()比GetIfTable()更准
GetIfTable()返回的是32位计数器，高流量下易溢出导致速率突降为负值；而GetIfEntry2()（Windows 8+）返回64位Uptime和Bytes字段，且自带时间戳，可规避手动计时误差。关键点在于必须调用ConvertInterfaceIndexToLuid()将接口索引转为NET_LUID，再传给GetIfEntry2()，否则会返回ERROR_INVALID_PARAMETER。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 先用
GetIfTable2()枚举所有接口，过滤OperStatus == IfOperStatusUp且InterfaceDescription含关键词（如"Ethernet"或"Wi-Fi"） - 每次调用
GetIfEntry2()前需清零结构体并设置Size字段，否则可能读到脏内存 - 速率计算用
(bytes_now - bytes_prev) / (time_now - time_prev)，单位是字节/秒，别忘了乘8转为bps - 若程序需兼容Win7，只能退回到
GetIfTable()+ 溢出检测逻辑（比较前后值是否异常变小）
跨平台封装要注意采样时机与精度损失
不要在每次查询时都重新打开/读取/解析系统文件或API——高频调用（如10Hz以上）会导致I/O瓶颈或系统调用开销陡增。正确做法是维护一个后台线程定时采集原始数据（如每200ms一次），主逻辑只读取最近缓存的差值。另外，std::chrono::steady_clock是唯一能准确测量真实流逝时间的时钟，system_clock可能因NTP校时跳变，导致速率计算结果剧烈抖动。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
std::atomic保护共享的rx_bytes、tx_bytes和timestamp，避免锁竞争 - 采样间隔设为200–500ms之间平衡响应性与稳定性；低于100ms时Linux下
/proc/net/dev更新频率可能跟不上 - Windows下
GetIfEntry2()返回的时间戳单位是100ns，但实际精度受限于系统时钟分辨率（通常15ms），别期望亚毫秒级精度 - 最终速率建议用滑动窗口（如最近3次采样）做简单中位数滤波，剔除偶发毛刺
常见错误：把ifconfig输出当实时依据
ifconfig（或ip -s link）显示的是累计值，不是瞬时速率。有人用std::system("ifconfig eth0 | grep 'RX bytes'")截取并解析，这不仅效率极低（fork+exec开销大），而且两次调用间可能被其他进程修改了同一接口的统计值（如DHCP重绑、防火墙规则刷新），导致差值为负或远超物理带宽。更糟的是，某些容器环境（如Docker with net=host）中ifconfig可能显示宿主机接口，而非容器实际使用的veth pair。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 彻底放弃shell命令调用，改用原生系统接口
- 验证数据合理性：若算出速率>1Gbps但物理网卡是100M，大概率是计数器溢出或接口识别错误
- 调试时用
watch -n 0.5 cat /proc/net/dev（Linux）或netstat -e（Windows）人工比对原始数据，确认你的解析逻辑没丢列
实际落地时，最难的不是读数据，而是判断“哪个接口才是用户真正关心的那个”——虚拟网卡、隧道接口、桥接设备常与物理接口同名或混排，得结合IFF_UP、MTU、Speed甚至ARP表来交叉验证。这点容易被忽略，但线上出问题时90%源于此。
