根本原因是ip与net.ipnet版本不匹配或ip为nil；实操需用net.parsecidr解析、校验ip类型、显式转换；点分掩码需转前缀长度；合并cidr应按网络大小逆序排序；高频contains应预处理或用前缀树优化。
为什么 net.IPNet.Contains 有时返回 false，明明 IP 看起来在网段里？
根本原因常是 IP 和 *net.IPNet 的版本不匹配：IPv4 地址传给了 IPv6 网段（或反之），或者 IP 是 nil。Go 的 net.IP 是字节切片，不会自动做地址族对齐——比如 net.ParseIP("192.168.1.1") 返回的是 4 字节切片，但若你用它去比对一个从 CIDR "::/0" 解析出的 IPv6 *net.IPNet，Contains 必然返回 false，连 panic 都不会触发。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 始终用
net.ParseCIDR解析网段，别手动构造IPNet；它会自动设置IPNet.Mask并对齐IP长度 - 比对前加一层校验：
ip.To4() != nil或ip.To16() != nil，确认 IP 类型 - 如果必须跨版本处理（如 IPv4-mapped IPv6），显式转换：
ip = ip.To4()再传入 IPv4 网段的Contains
如何正确解析并标准化用户输入的子网掩码（如 "192.168.1.0/255.255.255.0"）？
net.ParseCIDR 只认 IP/mask-bits 格式（如 "192.168.1.0/24"），遇到点分十进制掩码会直接返回 error。这不是 bug，是设计使然：Go 把掩码位数当作唯一权威表示，避免 255.255.255.128 这类非连续掩码带来的歧义。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先用正则粗筛输入格式：
^(\d{1,3}\.){3}\d{1,3}/(\d{1,3}\.){3}\d{1,3}$ - 解析掩码部分为
net.IPMask：mask := net.ParseIP(maskStr).To4()，再调用mask.Size()得到前缀长度 - 用得到的前缀长度拼回标准 CIDR 字符串，再喂给
net.ParseCIDR - 注意：
net.IPMask的Size()对非法掩码（如255.255.254.0）返回(0, 0)，需提前校验是否为有效网络掩码
多个 CIDR 网段合并时，为什么 net.IPNet.Mask.Size() 不能直接拿来排序？
因为 Size() 返回的是“网络位长度”，数值越小代表网段越大（如 /0 > /24）。直接按 Size() 升序排，会把大网段排在后面，导致合并逻辑错乱——比如你想先用 0.0.0.0/0 覆盖所有流量，结果它被排到最后才处理。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 排序时用
32 - net.IPNet.Mask.Size()（IPv4）或128 - net.IPNet.Mask.Size()（IPv6）作为权重，数值越小优先级越高 - 更稳妥的做法：统一转成
net.IPNet.IP.Mask(net.IPNet.Mask)归一化网络地址，再按IP.String()+ 掩码长度双关键字排序 - 别依赖
String()输出排序——它对 IPv6 输出带压缩，"2001:db8::/32"和"2001:db8:0000::/32"字符串不同但语义相同
用 net.IPNet.Contains 做高频 ACL 判断，性能瓶颈在哪？
单次调用没问题，但循环遍历上百个 *net.IPNet 做 Contains，会反复执行位运算和字节比较。更隐蔽的问题是：net.IPNet.Contains 内部没有缓存，每次调用都重新计算 ip.Mask(mask)，而 Mask 方法本身要复制 IP 字节切片——对短生命周期的临时 IP（如 HTTP 请求头里的 X-Forwarded-For），GC 压力明显上升。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 预处理阶段就把所有网段的网络地址和掩码长度存为
[16]byte（IPv6 安全）+int，避免运行时重复Mask - 对固定规则集，考虑构建前缀树（如
github.com/netsampler/gobgp/packet/bgp里的PrefixTree），比线性扫描快 1~2 个数量级 - 如果只是黑白名单且 CIDR 数量 sort.Search 做二分查找（需先按网络地址排序）比盲目优化更实际
真正难的不是算对，而是让不同来源的 CIDR（用户填的、配置文件读的、API 返回的）在类型、长度、归一化上保持一致。少一次 To4() 失败，就少一个半夜告警。
