net.ParseCIDR解析失败主因是输入含空格、BOM、中文标点等不可见字符，需strings.TrimSpace()预处理；IPv6必须用方括号包裹；网络地址须用IP.Mask(Mask)计算，不可直接用IPNet.IP。
net.ParseCIDR 解析失败的常见报错和原因
直接调用 net.ParseCIDR("192.168.1.0/24") 看似简单，但实际中常遇到 invalid CIDR address 或返回 nil。根本原因不是格式写错，而是输入字符串带空格、换行、BOM头，或用了中文标点（比如全角斜杠）。Go 的 net.ParseCIDR 对输入极其严格，不自动 trim，也不容忍任何非 ASCII 字符。
- 检查输入前先做
strings.TrimSpace()，尤其从配置文件、HTTP 查询参数或用户输入读取时 - 避免用
fmt.Sscanf或拼接字符串生成 CIDR 字符串，容易混入不可见字符 - IPv6 地址必须用方括号包裹：正确是
"[2001:db8::]/32"，错写成"2001:db8::/32"会解析失败
解析后怎么拿到网络地址、掩码长度和可用 IP 范围
net.ParseCIDR 返回一个 *net.IPNet，它本身不存“起始 IP”和“结束 IP”，得靠方法推导。别直接用 IPNet.IP 当网络地址——它可能是主机位非零的值（比如传入 "192.168.1.5/24"，IPNet.IP 就是 192.168.1.5，不是 192.168.1.0）。
- 网络地址必须用
IPNet.IP.Mask(IPNet.Mask)计算，例如：network := ipnet.IP.Mask(ipnet.Mask) - 掩码长度用
IPNet.Mask.Size()获取，返回两个 int：前一个是前缀位数（如 24），后一个是总位数（IPv4 是 32，IPv6 是 128） - 广播地址 = 网络地址 | ^掩码，但 Go 没内置方法，需手动按字节或 uint32/uint64 运算；更稳妥是用
IPNet.Contains遍历边界，或借助第三方库如github.com/malfunkt/iprange
IPv4 和 IPv6 在 ParseCIDR 中的行为差异
同一个函数处理两种协议，但底层逻辑不同，容易踩坑。最典型的是：IPv6 的 /128 表示单个地址，而 IPv4 的 /32 才等价；但 net.ParseCIDR("::1/128") 和 net.ParseCIDR("127.0.0.1/32") 都合法，且 IPNet.Contains 行为一致。真正要注意的是地址长度和掩码计算方式。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- IPv6 地址长度是 16 字节，
IP.To4()对 IPv6 返回nil，别在解析后无条件调用 -
IPNet.Mask返回的掩码是net.IPMask类型，对 IPv6 是 16 字节切片，对 IPv4 是 4 字节——做位运算时不能假设长度 - 用
IPNet.String()输出时，IPv6 默认不压缩（如"2001:0db8:0000:0000:0000:0000:0000:0000/32"），要美观显示需额外调用IP.String()再格式化
性能敏感场景下要不要缓存 ParseCIDR 结果
如果频繁校验大量请求是否命中某个 CIDR（比如 ACL 列表），每次调用 net.ParseCIDR + IPNet.Contains 会有明显开销。因为 ParseCIDR 内部要做字符串分割、进制转换、掩码生成，而 Contains 是逐字节 & 运算，虽快但叠加起来可观。
- 预解析所有 CIDR 到
[]*net.IPNet并复用，比每次解析快 3–5 倍（实测万级请求） - 若 CIDR 数量极大（>1000），考虑构建前缀树（如
github.com/google/gopacket/routing中的table）替代线性遍历 - 注意：不能把
*net.IPNet当 key 存 map，因为其结构含 slice，不可比较；要用字符串（如ipnet.String()）作 key
实际用的时候，最易忽略的是输入清洗和网络地址归一化——很多人卡在明明字符串看着对，却解析失败，或者用 IPNet.IP 直接当网段起始地址，结果范围算偏了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
