libpcap打开设备失败最常见原因是权限不足或设备名错误；返回nullptr时须调用pcap_geterr()获取具体错误，如“Permission denied”或“No such device exists”，并用pcap_findalldevs()枚举真实接口名。
libpcap打开设备失败时怎么查原因
最常见的是权限不足或设备名错误，pcap_open_live() 返回 nullptr 时，别只看返回值，必须调用 pcap_geterr() 获取具体错误信息。
- Linux 下没加
sudo或没配置capabilities（如cap_net_raw+ep），会报“Permission denied” - 设备名写成
"eth0"但实际是"enp0s3"或"wlp2s0"，可用pcap_findalldevs()列出真实接口名 - 接口已关闭（
ifconfig enp0s3 down）也会失败，错误提示常为“No such device exists”
如何正确捕获一个完整封包（含链路层头）
pcap_next_ex() 默认返回的是从链路层开始的原始字节流，比如以太网帧包含 14 字节 MAC 头，IP 层数据从第 14 字节起——这点容易被忽略，导致解析 IP 头时偏移错。
- 用
pcap_datalink()确认链路类型：返回DLT_EN10MB表示以太网，DLT_LINUX_SLL表示 Linux cooked capture（无 MAC 头，带 16 字节伪头） - 不要硬编码跳过 14 字节；应根据
pcap_datalink()结果动态计算 payload 起始位置 - 示例：若
linktype == DLT_EN10MB，则 IP 头在packet + 14；若为DLT_LINUX_SLL，则 IP 头在packet + 16
为什么回调模式（pcap_loop）比轮询（pcap_next_ex）更可靠
在高吞吐场景下，pcap_next_ex() 容易丢包，因为用户代码处理慢会导致内核缓冲区溢出；而 pcap_loop() 配合回调函数能更快移交数据，减少拷贝延迟。
-
pcap_loop()内部使用select()/poll()等机制，响应更及时 - 回调函数签名必须是
void handler(u_char *user, const struct pcap_pkthdr *h, const u_char *bytes)，user参数可用于传入上下文对象指针 - 注意：回调中避免做耗时操作（如文件 I/O、复杂解析），否则仍会拖慢捕获速度
libpcap 在不同平台读取封包的差异点
Windows 上用 WinPcap 或 Npcap，行为和 Linux 不完全一致，尤其在混杂模式和时间戳精度上。
立即学习“C++免费学习笔记（深入）”；
- Windows 下默认不启用混杂模式，需显式调用
pcap_set_promisc(handle, 1)并在pcap_open_live()前设置 - 时间戳字段
pkthdr->ts在 Windows 上可能只有毫秒级精度（取决于驱动），Linux 通常支持微秒或纳秒（依赖内核和硬件） - macOS 使用
libpcap底层是BPF，接口名常为"en0"，且部分无线接口不支持混杂模式，pcap_open_live()可能静默降级
