net.Interface 返回空或 panic 的根本原因是运行环境限制：容器默认仅暴露 loopback、无 root 权限导致接口不可见、IPv6 未启用影响地址枚举；需检查 Flags 判断真实网卡，Addrs() 需用 To4() 筛 IPv4，HardwareAddr 在 macOS 沙盒下常为 nil。
net.Interface 为什么返回空或 panic？
直接调用 net.Interfaces() 却拿不到预期网卡，常见于容器环境、无 root 权限或系统未启用 IPv6 的场景。它本身不报错，但返回的切片可能为空；若后续对 nil 接口调用 Interface.Addrs() 就会 panic。
- Linux 容器里默认只暴露 loopback，需加
--cap-add=NET_ADMIN或挂载/sys/class/net - macOS 上某些虚拟网卡（如 Parallels）可能被内核过滤，
net.Interface不可见 - Windows 下需管理员权限才能枚举所有接口，否则跳过部分物理适配器
- 别在 defer 里直接用
iface.HardwareAddr.String()——iface.HardwareAddr可能为nil，先判空
如何区分真实网卡和虚拟/回环接口？
net.Interface.Flags 是唯一可靠依据，不能靠名字匹配（比如 Linux 的 docker0、vethxxx，macOS 的 utun 都可能有有效 IP）。
- 必须同时满足：
iface.Flags&net.FlagUp != 0（已启用）且iface.Flags&net.FlagLoopback == 0（非回环） - 虚拟网卡通常带
net.FlagBroadcast但缺net.FlagMulticast，不过这不绝对，仅作辅助判断 - 别用
strings.HasPrefix(iface.Name, "lo")过滤 —— FreeBSD 用lo0，Solaris 用lo，硬编码易漏
获取 IP 地址时，Addrs() 返回的 *net.IPNet 为什么经常是 IPv6？
iface.Addrs() 返回的是该接口绑定的所有地址，顺序无保证。现代系统默认启用 IPv6，即使你只配了 IPv4，::1 或 fe80::/64 链路本地地址也一定存在。
- 遍历时务必检查
ipnet.IP.To4() != nil来筛 IPv4，而不是用strings.Contains等字符串操作 -
net.ParseCIDR("127.0.0.1/32")得到的*net.IPNet和iface.Addrs()里返回的不是同一类对象：前者是解析结果，后者是内核实际绑定的地址段 - 注意
127.0.0.1/8在 loopback 接口上是合法的，但其他接口若出现该网段，大概率是误配置或容器桥接残留
跨平台获取 MAC 地址失败的真正原因
iface.HardwareAddr 在 Windows 和 Linux 上行为一致，但在 macOS 上——从 10.15（Catalina）开始，沙盒应用默认无法读取真实 MAC，返回全零或随机化值；非沙盒程序也需用户授权（首次运行弹窗），否则字段为 nil。
立即学习“go语言免费学习笔记（深入）”；
- 不要假设
HardwareAddr总是非空，始终用if ha := iface.HardwareAddr; ha != nil包裹 - macOS 上可通过
sysctl -n net.link.generic.system.hwaddr命令绕过（需权限），但 Go 标准库不提供此路径 - 某些云主机（如 AWS EC2）的弹性网卡在热插拔后，
HardwareAddr可能延迟更新，建议加短时重试逻辑而非单次读取
真实网络诊断中，最麻烦的从来不是“怎么拿到数据”，而是“拿到的数据是否可信”——尤其当 net.Interface 暴露的是内核视图，而用户看到的是 ifconfig / ip addr 的抽象层时，两者之间总有一层没说破的映射关系。
