gopacket不自动重组TCP流、不处理TLS、不识别chunked编码、不支持pcapng；四大易错点为权限（Linux需setcap、macOS需动态查接口）、链路层类型（须handle.LinkType()获取而非硬编码）、文件格式（仅支持libpcap，pcapng需tshark转换）、HTTP解析（LayerTypeHTTP仅对完整报文头有效，需tcpassembly或关键词匹配）。
gopacket 不是“调通
pcap.OpenLive 就能抓到 HTTP 包”的库——它不自动重组 TCP 流、不处理 TLS、不识别 chunked 编码、也不支持 pcapng。你看到的空层、nil 返回、静默失败，几乎都卡在这四个点上：权限、链路层类型、文件格式、HTTP 解析逻辑。
Linux/macOS 下 pcap.OpenLive 报 permission denied 怎么办
这不是代码 bug，是进程没拿到原始套接字权限。硬加
sudo 跑只是临时解法，还放大攻击面。
- Linux：用
setcap cap_net_raw+ep ./your-binary 赋权，之后普通用户可直接运行，且只开放网络抓包能力，不提权
- macOS：SIP 可能屏蔽部分接口，
en0 是常见首选，但不能硬写；必须先调 pcap.FindAllDevs()，过滤掉 Devices[i].Addresses 全是 127.0.0.1 或 ::1 的设备再选
- Windows：静默失败大概率因没装 Npcap（WinPcap 已停更），安装后务必勾选 “WinPcap compatibility mode”
pcap.OpenOffline 打不开 Wireshark 导出的 .pcap 文件
gopacket 原生不支持 pcapng 格式，而 Wireshark 默认导出就是 pcapng。它不会报错，而是
packetSource.Next() 立即返回
nil，接着调
packet.Layer() 就 panic。
- 用系统命令确认：
file your.pcap，输出含 tcpdump 或 libpcap → 可用；含 pcap-ng → 不可用
- Wireshark 正确导出路径：
File → Export Packet Dissections → As PCAP (libpcap)
- 已有 pcapng？用
tshark -F libpcap -r input.pcapng -w output.pcap 转换
packet.Layer(layers.LayerTypeHTTP) 总是 nil
这不是包里没 HTTP，是
gopacket 默认不解析 TCP 流——它只对“单个 TCP 包里恰好含完整 HTTP 报文头”有效，现实中几乎不存在。
- 别在循环里对每个
tcp.Payload 直接调 http.ReadRequest，它需要完整未分片流，而 pcap 抓的是帧
- 简单可靠方案：
bytes.Contains(tcpLayer.Payload(), []byte("GET ")) 做关键词匹配（注意大小写和空格）
- 真要还原完整请求/响应：必须上
gopacket/tcpassembly，自己维护 streamFactory 和超时清理逻辑，否则内存持续增长
链路层类型写死导致上层全丢
硬编码
LinkTypeEthernet 等于放弃解码。真实链路层取决于抓包方式和平台：
any 接口在 Linux 上是
LinkTypeLinuxSLL（值 113），环回是
LinkTypeNull（值 0），VLAN 环境可能带 802.1Q 标签。
- 必须用
handle.LinkType() 动态获取，而不是查文档猜值
- 创建
DecodingLayerParser 时，第一个参数必须和这个值一致，例如：gopacket.NewDecodingLayerParser(handle.LinkType(), ...)
- 过滤器也要适配链路层：BPF 表达式
ip and port 80 在 DLT_LINUX_SLL 下可能不生效，得先确认封装结构
链路层类型不对、文件格式误判、HTTP 解析逻辑错位——这三处最容易被当成“库有问题”，实际只是没绕开 gopacket 的设计边界。它不做流重组、不兼容 pcapng、不越权提权，所有“看似该有却没出现”的东西，基本都卡在这些显式约束里。
