标准C++库无法直接发ARP请求，因其工作在链路层且需原始套接字权限；推荐用arping工具、libpcap抓包或ioctl/SIOCGARP查缓存，按场景选择最优方案。
为什么不能直接用标准C++库发ARP请求
标准C++没有提供ARP协议的封装接口，std::net（C++23草案）也不包含链路层操作能力。ARP工作在OSI第二层，需要原始套接字（raw socket）或内核态支持，而跨平台标准库刻意回避这类权限敏感操作。Linux/macOS需root或CAP_NET_RAW，Windows需NDIS或WinPcap/WinDivert等第三方驱动支撑。
Linux下用arping命令快速探测设备
最轻量、最可靠的方式是调用系统已有的arping工具——它本质就是用户态ARP请求发送器，无需自己构造以太网帧。注意它默认只发单个请求，要覆盖整个子网得配合循环。
常见用法示例：
arping -c 1 -w 0.5 192.168.1.10
关键参数说明：
立即学习“C++免费学习笔记（深入）”；
-
-c 1：只发1个ARP请求，避免阻塞 -
-w 0.5：超时0.5秒，适合批量扫描 -
192.168.1.10：目标IP，需确保在同一子网且路由可达
返回值为0表示收到ARP响应（即设备在线且MAC已缓存），非0则无应答。注意：某些设备（如iOS手机）可能静默丢弃未请求的ARP，或启用了ARP限速，导致漏检。
用libpcap捕获ARP响应并解析
若需自主控制流程（比如监听全网ARP广播、区分请求/响应、提取源MAC），libpcap是更底层但跨平台的选择。它不发包，只抓包，所以必须先触发ARP（如用ping或arping），再监听回应。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
核心步骤：
- 用
pcap_open_live()打开混杂模式接口（需权限） - 设置BPF过滤器：
"arp and arp[6:2] = 2"（只取ARP reply） - 调用
pcap_next_ex()获取包，用ethernet_header和arp_header结构体偏移解析MAC
容易踩的坑：
- ARP缓存存在时，目标可能不发响应（本地已有记录），需先
arp -d IP清缓存 -
libpcap抓到的是链路层帧，MAC地址在以太网头前14字节，不是ARP payload里——新手常在这里错位读取 - Windows上
NPF驱动可能拦截ARP包，导致libpcap收不到，建议改用WinDivert
C++调用ioctl(SIOCGARP)查本地ARP缓存
这是最快、最安全的方式——不发包、不抓包，只读内核ARP表。适用于“设备刚通信过，MAC大概率已在缓存中”的场景。Linux和Windows都支持，但API不同。
Linux示例（需<net/if_arp.h>）：
struct arpreq req = {};
inet_aton("192.168.1.5", &req.arp_pa);
req.arp_flags = ATF_COM;
ioctl(sock, SIOCGARP, &req); // 成功则req.arp_ha.sa_data含MAC
Windows对应用GetIpNetTable2()（iphlpapi.h），返回MIB_IPNET_ROW2结构，PhysicalAddress字段即MAC。
限制明显：
- 只能查本机ARP缓存中存在的条目，新设备或长时间未通信的设备不会出现
- 缓存条目有老化时间（Linux默认300秒），过期后自动删除
- 某些嵌入式设备或容器网络可能禁用ARP缓存，返回空
真正难的不是构造ARP包，而是判断什么时候该用哪种方式：扫新设备优先用arping，查历史连接用SIOCGARP，做中间人或协议分析才上libpcap。多数业务场景其实只需要前者加缓存回查就够了。
