Windows无直接获取实时丢包率API，须用GetIfTable2两次采样ifInDiscards/ifInUcastPkts差值计算，因系统仅维护累计丢包数且部分网卡不更新该值。
Windows 上没有直接返回“实时丢包率”的 API，必须靠两次采样 ifInDiscards/ifOutDiscards 与 ifInUcastPkts/ifOutUcastPkts 的差值手动计算；用 GetIfTable2 是唯一推荐方式，GetIfTable 在高吞吐或虚拟网卡下容易漏计数。
为什么不能直接读取丢包率？
Windows 网络栈不维护“丢包百分比”这个瞬时指标。所有丢包相关字段（如 ifInDiscards、ifInErrors）都是累计值，单位是“包数”，且只在驱动层上报——有些虚拟网卡（如 WSL2 vEthernet）根本不更新 ifInDiscards，Wi-Fi 驱动也可能将部分错误归入 ifInErrors 而非 ifInDiscards。
常见误操作包括：
- 调用
GetIfEntry或GetIfTable读取旧版MIB_IFROW：其dwInDiscards字段在千兆以上速率下易溢出（DWORD），且不支持 IPv6 接口 - 依赖性能计数器路径如
"\Network Interface(*)\Packets Discarded"：该计数器在 Win10 1809+ 已被弃用，多数系统返回 0 或PDH_INVALID_DATA - 仅采样一次就除以总包数：丢包率必须是“单位时间内的丢弃包占比”，静态值毫无意义
用 GetIfTable2 计算入向丢包率（Inbound Packet Loss Rate）
核心逻辑是：取间隔 1 秒的两次 GetIfTable2 结果，分别拿到 ifInDiscards 和 ifInUcastPkts，再按公式 (ΔifInDiscards / ΔifInUcastPkts) * 100.0 计算百分比。注意分母为 0 时跳过。
关键实操点：
- 必须检查
pIfRow->OperStatus == IfOperStatusUp，否则ifInDiscards可能停滞不更新 -
ifInUcastPkts是无符号 64 位整数，两次差值要用INT64存储，防止回绕（尤其在高速网卡上 1 秒可能收数百万包） - 不要用
sleep(1000)控制间隔：调度延迟会导致 Δt 偏离 1s，建议用QueryPerformanceCounter自适应等待（见知识库示例） - 若
ΔifInUcastPkts == 0（比如空闲链路），丢包率视为 0% 或标记为 “N/A”，避免除零崩溃
出向丢包率（Outbound）和错包率（Error Rate）怎么算？
出向丢包率同理，用 ifOutDiscards / ifOutUcastPkts；错包率则应合并 ifInErrors + ifOutErrors 与总收发包数之和计算，但要注意：
-
ifInErrors包含 CRC 错误、超长帧等底层错误，而ifInDiscards更偏向协议栈丢弃（如内存不足、队列满） - 某些网卡驱动把重传包也计入
ifOutUcastPkts，导致分母虚高，此时丢包率偏低——这是驱动行为，无法跨厂商统一修正 - Wi-Fi 适配器的
ifOutErrors常远高于有线，但多数属于正常重传范畴，不应简单等同于“故障”
容易被忽略的兼容性坑
最常被跳过的其实是权限和释放问题：
-
GetIfTable2返回的PMIB_IF_TABLE2指针必须用FreeMibTable释放，否则每次调用泄漏约 4–8KB 内存（尤其轮询场景下几小时就 OOM） - 低权限进程（如 UAC 虚拟化后的控制台）可能读不到物理网卡的
ifInDiscards，但能读到 Loopback 或 WSL2 接口——建议先用GetAdaptersAddresses过滤出IF_TYPE_ETHERNET_CSMACD类型接口再查 - Hyper-V 虚拟交换机端口的丢包统计通常不可靠，
ifInDiscards值长期为 0，此时应降级为日志告警而非报错
真正稳定的实现，永远是“采样 → 差值 → 检查状态 → 防除零 → 释放内存”这五步闭环，少一步都可能在某类硬件或系统版本上静默失效。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
