常见原因是链路层不匹配、未流重组tcp、解码器未裁剪：需用handle.linktype()获取真实链路层类型并传给decodinglayerparser；http解析必须配合tcpassembly流重组；禁用无用协议层解码可提升性能。
用 gopacket 读取 PCAP 文件时程序 panic 或返回空包
常见原因是没正确处理文件打开失败或数据链路层不兼容。比如用 pcap.OpenOffline 打开一个被截断的 PCAP、或 Wireshark 导出的 pcapng 格式（gopacket 默认不支持），都会导致 packetSource.Next() 立即返回 nil，接着对 nil 调用 Layer 就 panic。
- 先确认文件是标准 pcap（不是 pcapng）：用
file your_file.pcap查看，输出含tcpdump或libpcap字样才安全 - 用
os.Open显式检查错误，别直接传给pcap.OpenOffline - 初始化
packetSource后，加一行if err := packetSource.Err(); err != nil { log.Fatal(err) }，很多问题在这里暴露 - Wireshark 导出时选 “PCAP (libpcap)” 格式，别选 “PCAPNG”
gopacket.DecodeLayers 解析不出 TCP/UDP 层，NetworkLayer 总是 nil
根本原因在于链路层封装类型没匹配上。比如抓包来自以太网（LinkTypeEthernet），但你用 layers.LinkTypeNull 初始化解码器，上层协议就全丢了。
- 从
*pcap.Handle拿真实链路层类型：handle.LinkType()，打印出来看看是不是1（Ethernet）、12（Raw IP）、113（Linux SLL）等 - 创建
gopacket.DecodingLayerParser时，第一个参数必须和实际链路层一致；常见写法：gopacket.NewDecodingLayerParser(layers.LinkTypeEthernet, ...) - 如果抓包来自 Linux 的
any接口（如tcpdump -i any），链路层通常是LinkTypeLinuxSLL，不是 Ethernet - 不要硬编码
LinkTypeEthernet—— 它只适用于 .pcap 来自物理网卡且未做特殊导出的情况
解析 HTTP 流量时拿不到完整请求/响应体
gopacket 本身不重组 TCP 流，它只按包解析。单个 Packet 可能只含 HTTP 头的一部分，甚至只有 FIN 标志位，没有 payload。
- HTTP 解析必须配合流重组：用
gopacket/tcpassembly+gopacket/tcpassembly/tcpreader - 别在
packet.ApplicationLayer()上直接调Payload()—— 这只是当前包的应用层载荷，不是完整 HTTP 报文 - 流重组需要自己维护
streamFactory和streamPool，且注意超时清理，否则内存持续增长 - 简单场景下，可先用
packet.TransportLayer().LayerType() == layers.LayerTypeTCP过滤，再检查TCP层的SrcPort/DstPort是否为 80/443，但依然无法还原分片传输的 HTTP
性能差：解析 100MB PCAP 耗时超过分钟级
默认配置下 gopacket 会尝试解析所有已知协议层（包括 IPv6、ICMPv6、BGP 等），哪怕你的文件全是 IPv4+TCP+HTTP。这是最大性能陷阱。
立即学习“go语言免费学习笔记（深入）”；
- 禁用无用解码器：初始化
DecodingLayerParser时只传入真正需要的层，例如[]gopacket.LayerType{layers.LayerTypeIPv4, layers.LayerTypeTCP, layers.LayerTypeHTTP} - 避免反复调用
packet.Layer(layers.LayerTypeXXX)—— 改用packet.NetworkLayer()/packet.TransportLayer()这类快速访问器 - 不用
gopacket.ParsePacketFast（它只做基础解析，不填协议字段），而用gopacket.DecodeLayers配合最小 layer 列表 - 如果只关心 IP 五元组和包长，跳过所有
Layer解析，直接读packet.Data()+ 手动偏移取 IP/TCP 头字段，快 5–10 倍
