权限、链路层类型、pcapng格式、HTTP流重组是gopacket抓包四大易错点：Linux需cap_net_raw权限，macOS需动态查接口；gopacket不支持pcapng；默认不解析分片/TLS/HTTP流；LinkType必须从handle获取而非硬编码。
pcap.OpenLive 权限失败：不是代码问题，是系统没给权
Linux/macOS 下直接运行 pcap.OpenLive 报 permission denied，不是你写错了，是进程缺 CAP_NET_RAW 能力。Windows 则大概率因没装 Npcap/WinPcap 静默失败——错误信息可能根本不出现在日志里。
- Linux 推荐用
sudo setcap cap_net_raw+ep ./your-binary赋权，比每次sudo ./your-binary更安全可控 - macOS 上
en0是首选，但 SIP 可能屏蔽部分接口；先跑pcap.FindAllDevs()看输出，确认Devices[i].Description不为空、且Devices[i].Addresses有非 loopback 地址再选 - 别硬写
"eth0"或"en0"——虚拟机、Docker、云主机的接口名千差万别，必须动态查
解析 HTTP 失败：gopacket.LayerTypeHTTP 不是万能钥匙
直接调 packet.Layer(layers.LayerTypeHTTP) 返回 nil 是常态，不是包里没 HTTP，而是 gopacket 默认不重组 TCP 流，也不处理分片、重传、TLS 加密或 chunked 编码。
-
layers.LayerTypeHTTP只对“单个 TCP 包里恰好含完整 HTTP 报文头”有效，现实网络中几乎不存在这种理想包 - Wireshark 能显示 HTTP 是因为它后台做了流重组 + 解密 + 解压缩；gopacket 不做这些，它只解帧、解 IP、解 TCP，到此为止
- 真要分析 HTTP 内容，要么用
gopacket/tcpassembly自建流池（复杂、需清理超时连接），要么退一步：用bytes.Contains(tcp.Payload, []byte("GET "))做关键词匹配，简单但可靠
pcapng 文件打不开：gopacket 不支持，别怪代码
用 Wireshark 导出抓包文件时选了 PCAPNG 格式，pcap.OpenOffline 就会静默失败——packetSource.Next() 立即返回 nil，接着调 packet.Layer(...) 就 panic。这不是 bug，是设计如此。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先用系统命令确认格式：
file your.pcap，输出含tcpdump或libpcap才是标准 pcap；含pcap-ng就是 pcapng，gopacket 原生不认 - Wireshark 导出时务必选
PCAP (libpcap)，不是PCAPNG，也不是JSON或CSV - 若只有 pcapng 文件，可用
tshark -F libpcap -r input.pcapng -w output.pcap转换，tshark 本身支持 pcapng
LinkType 不匹配：链路层类型写死 = 白忙活
抓包来自 Linux any 接口，却用 layers.LinkTypeEthernet 初始化解码器，结果 NetworkLayer 总是 nil——因为真实链路层是 LinkTypeLinuxSLL（值为 113），不是以太网（值为 1）。
- 永远从
*pcap.Handle拿真实类型：handle.LinkType()，打印出来看看是 1、12、113 还是别的 -
gopacket.NewDecodingLayerParser第一个参数必须和handle.LinkType()一致；常见组合：LinkTypeEthernet（物理网卡）、LinkTypeLinuxSLL（tcpdump -i any）、LinkTypeNull（lo回环） - 别在代码里写死
LinkTypeEthernet——它只适用于最朴素的物理网卡抓包场景，其他情况基本不准
链路层类型、文件格式、权限、流重组，这四点漏掉任一个，抓包程序就停在“看似运行但啥也看不到”的状态。它们不报错，也不提示，只是沉默地返回 nil 或空值——这才是最耗时间的地方。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
