net.InterfaceAddr 返回空或无MAC是设计限制：Linux需CAP_NET_RAW/root权限，macOS需全盘访问（12.0+），Windows依赖WMI；须显式检查HardwareAddr是否nil，不可直接调用String()。
net.InterfaceAddr 为什么返回空或不包含 MAC？
Go 的 net.Interface 默认只暴露 IP 地址信息，HardwareAddr 字段在某些系统或权限不足时为 nil —— 不是 bug，是设计限制。Linux 下需 CAP_NET_RAW 或 root；macOS 需要全盘访问权限（12.0+）；Windows 则依赖 WMI 权限。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
net.Interfaces()获取接口列表后，必须显式检查iface.HardwareAddr != nil，不能直接调用String() - Linux 下若非 root 运行，可改用
sysctl -n net.ipv4.conf.all.forwarding等间接方式判断网卡活跃性，避免硬依赖 MAC - macOS 上即使有权限，部分虚拟网卡（如 utun、bridge）也可能无 MAC，应跳过而非 panic
从 IPv4Addr 推导掩码长度的坑：/32 不等于本地回环
*net.IPNet.Mask.Size() 是最常用解法，但容易忽略两个现实问题：一是接口可能绑定了多个 CIDR（比如 Docker 的 docker0 常带 172.17.0.1/16 和额外的 /32 host 路由），二是某些系统（如 OpenWrt）会把点对点链路配成 /32 却仍需按真实子网处理。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 遍历
iface.Addrs()时，只取net.IPNet类型地址，过滤掉net.IPAddr（后者无掩码） - 对每个
*net.IPNet，用ipNet.Mask.Size()获取前缀长度，别手写位运算——Go 标准库已优化 - 若发现
/32且 IP 不是127.0.0.1或::1，大概率是点对点或容器 host-local 地址，需结合路由表（net.RouteTable()）交叉验证实际出口网段
跨平台获取默认网关和关联接口名的实际路径
Go 标准库不提供直接获取“默认网关绑定在哪张网卡”的 API。net.DefaultRoute() 在 Go 1.22+ 才引入，且 Windows 下返回的 Interface 字段常为空；老版本只能靠解析 netstat -rn 或 ip route show default 输出，稳定性差。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 优先用
net.Interfaces()+iface.Addrs()找出所有含 IPv4 的活跃接口，再对每个接口执行net.LookupHost("1.1.1.1")并抓包看走哪张卡（仅调试用） - 生产环境推荐调用系统命令：
route -n get default 2>/dev/null | grep interface | awk '{print $2}'（macOS）、ip route | awk '/^default/ {print $5; exit}'（Linux） - 注意 Windows 的
route print -4输出格式混乱，建议用Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Select-Object -ExpandProperty InterfaceAlias（PowerShell）并加超时控制
嗅探失败时如何快速定位是权限、驱动还是 Go 版本问题？
常见错误现象：nil 的 HardwareAddr、no such device 错误、operation not permitted、甚至 net.Interfaces() 返回空切片——这些背后原因差异极大。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先确认 Go 版本：
go version，低于 1.19 的net.Interface在 macOS 上对虚拟接口支持极弱 - Linux 下运行
ls -l /sys/class/net/*/address 2>/dev/null | head -5，看是否真能读到物理地址；若能读但 Go 读不到，基本是权限问题 - 用
strace -e trace=ioctl,getifaddrs go run main.go 2>&1 | grep -i mac（Linux）或dtruss -f go run main.go 2>&1 | grep -i bpf（macOS）看底层系统调用是否被拒
真正麻烦的是那些没报错但数据不对的情况：比如容器内看到的是 veth 对端 MAC，不是宿主机网卡 MAC。这种得靠 /proc/sys/net/ipv4/conf/*/forwarding 和 /sys/class/net/*/device/vendor 组合判断设备类型，没法靠一个 net 包搞定。
