net.listentcp无法捕获经过本机的流量，因其仅监听本机主动接受连接的端口，不接触ip层或数据链路层；需用gopacket等第三方库配合原始套接字与系统权限才能实现全流量抓包。
为什么 net.ListenTCP 不能抓到经过本机的流量
因为 net.ListenTCP 只监听自己主动接受连接的端口，它不接触 IP 层或数据链路层的数据包——换句话说，它看不见别人发给其他服务的包，也看不到本机转发的包。想监控“经过本机”的流量（比如目标是另一台机器但途经你、或本机作为网关时的转发流），必须绕过 socket API，直接读网卡原始帧。
- 常见错误现象：
listen tcp :8080: bind: address already in use或根本收不到非本机监听端口的通信 - 真实使用场景：调试容器间通信、排查中间代理行为、观察局域网某设备访问了哪些外部端口
- Go 标准库不支持 raw socket 抓包；必须依赖第三方库（如
gopacket）+ 底层权限（Linux 需cap_net_raw或 root） - Windows 下需 WinPcap/Npcap，macOS 需 libpcap + 权限弹窗，不是加个 flag 就能跑
用 gopacket 捕获特定端口的 TCP 流量
核心思路是：打开网卡混杂模式 → 过滤出 TCP 包 → 提取源/目的端口 → 判断是否命中目标端口。注意，这里“特定端口”指任意方向（进或出）含该端口号的 TCP 流量，不是仅限本机监听端口。
- 安装依赖：
go get github.com/google/gopacket和go get github.com/google/gopacket/pcap - 关键步骤：调用
pcap.OpenLive打开设备（如"eth0"），设置超时和缓冲区大小；用pcap.CompileFilter编译 BPF 过滤器，例如"tcp port 443" - 过滤器写法直接影响性能：用
"tcp port 80 or tcp port 443"比在 Go 层遍历所有包再判断快一个数量级 - 注意端口字段在 TCP 层，别误用 IP 层的
src host这类过滤条件
handle, _ := pcap.OpenLive("eth0", 1600, true, pcap.BlockForever)
filter := "tcp port 8080"
handle.SetBPFFilter(filter)如何避免只看到半截 TCP 流或丢包
原始抓包不是万能的，内核协议栈和用户态缓冲协同不好，很容易漏掉 SYN、FIN 或重传包，尤其高流量下。
- 默认缓冲区太小（
1600字节只够单个以太网帧）：设为1024 * 1024更稳妥，避免截断大包（如含 TLS record 的 TCP segment） - 不要在
PacketSource.NextPacket()循环里做耗时操作（如打印、写文件）：会拖慢读取速度，导致内核 ring buffer 溢出丢包 - 混杂模式下会收到广播/多播包，如果只关心点对点 TCP 流，建议加
"tcp and not broadcast and not multicast"过滤 - 某些云主机网卡（如 AWS ENA、GCP e1000）不支持混杂模式，此时
OpenLive会静默失败或返回空设备列表
为什么抓到的端口总是 0 或解析失败
典型原因是没正确解包层级。TCP 端口存在于 TCP 层，但你可能只解析到了 IP 层，或者用了错误的类型断言。
立即学习“go语言免费学习笔记（深入）”；
- 必须逐层解包：
packet.Layer(layers.LayerTypeEthernet)→packet.Layer(layers.LayerTypeIPv4)→packet.Layer(layers.LayerTypeTCP) - 错误写法：
tcp := packet.TransportLayer().(*layers.TCP)—— 如果包不是 TCP 类型，会 panic；应先用if tcp, ok := packet.TransportLayer().(*layers.TCP); ok - IPv6 场景下，
TransportLayer()可能返回*layers.UDP或 nil，别假设一定是 TCP - 某些 NAT 设备或负载均衡器会做端口转换，你看到的“目的端口”可能是被改写后的，和原始请求不一致
抓包这事，底层细节多、环境差异大，同一段代码在笔记本上跑通，换到 Docker 容器或 Kubernetes Pod 里大概率连设备都列不出来。真要稳定用，得先确认运行环境的抓包能力边界，而不是只调通一个 OpenLive。
