因为net.ipnet封装cidr标准化表示和位运算逻辑，可准确识别语义等价段、避免字符串解析开销与边界错误，而字符串切片无法处理“192.168.0.0/24”与“192.168.0.128/25”等价合并问题。
为什么用 net.IPNet 而不是字符串切片做 IP 段合并？
直接存 "192.168.0.0/24" 字符串再排序去重，看似简单，但会漏掉语义等价但格式不同的段（比如 "192.168.0.0/24" 和 "192.168.0.128/25" 实际可合并为前者）。net.IPNet 封装了 CIDR 的标准化表示和包含关系判断逻辑，底层用 IP.Mask 做位运算，避免字符串解析开销和边界错误。
实操建议：
- 所有输入字符串必须先通过
net.ParseCIDR()转成*net.IPNet，失败的条目要过滤或报错——常见错误是传入"10.0.0.1-10.0.0.255"这类非 CIDR 格式 - 合并前先调用
ipnet.IP = ipnet.IP.Mask(ipnet.Mask)归一化网络地址（否则"192.168.1.10/24"的 IP 字段不等于网络首地址） - 注意 IPv4 和 IPv6 不能混在同一个切片里比较，
net.IPNet.String()输出格式也不同，建议按协议族分组处理
如何用 sort.Slice + 自定义比较实现无重叠段合并？
标准库没有现成的 CIDR 合并函数，得自己写。核心是：先按网络地址升序，再按掩码长度降序（即更具体的段排前面），然后线性扫描，用 subnet.Contains(merged.Last().IP) 判断能否吸收。
实操建议：
- 比较函数里必须同时比
IP和Mask：IPv4 用bytes.Compare(a.IP, b.IP)，再比len(a.Mask)；IPv6 同理但注意net.IP是 16 字节 - 合并循环中，每次只尝试把当前段合并进上一个已合并段，而不是暴力两两比较——时间复杂度从 O(n²) 降到 O(n log n)
- 别忽略边界：两个段完全相等时要去重；一个段被另一个完全包含时要丢弃前者（例如
10.0.0.0/24包含10.0.0.128/25）
用 radix tree 还是 trie 做高效检索？
查某个 IP 是否在任意段内，用遍历合并后的 []*net.IPNet 是 O(n)，n 达万级时延迟明显。真正高效的方案是构建前缀树（trie），但 Go 标准库没提供，推荐用 github.com/hashicorp/go-multierror 配套的 cidranger 或轻量级 github.com/miekg/dns 里的 trie（仅 IPv4）。
实操建议：
-
cidranger内部用平衡二叉树模拟 trie，支持 IPv4/IPv6，插入 O(log n)，查询 O(log n)，但内存占用比纯 slice 高 3–5 倍 - 如果只查 IPv4 且段数 [4]byte 的 32 层 trie 更快（每层对应一位掩码），避免
net.IP分配和接口转换开销 - 注意：所有 trie 实现都要求输入段已归一化且无重叠，否则查询结果不可靠——必须先走完合并流程再建树
大规模场景下容易被忽略的内存与 GC 问题
处理百万级 IP 段时，net.ParseCIDR 每次都会 new 一个 net.IP 底层数组（IPv4 是 4 字节但分配 16 字节，IPv6 固定 16 字节），加上 net.IPNet 结构体本身，单个段约占用 80+ 字节。百万条就是 ~80MB，GC 压力陡增。
实操建议：
- 用
sync.Pool缓存net.IP和net.IPNet实例，尤其在解析阶段重复使用同一块内存 - 合并完成后，把最终结果转成紧凑结构：例如只存
uint32（IPv4 网络地址） +uint8（掩码长度），查的时候再临时构造net.IPNet，内存可降至原来的 1/3 - 避免在 HTTP handler 里反复解析同一份段列表——应预加载到全局变量或 sync.Once 初始化的 map 中
真正的难点不在算法，而在怎么让 net.IP 不逃逸、怎么让 trie 的节点复用、以及合并后如何序列化为 mmap 友好格式。这些细节不压测根本看不出问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
