net.IPNet.Contains返回false的常见原因是IP未标准化，如IPv4地址被解析为16字节IPv6映射格式，而IPv4网段要求4字节；应使用ip.To4()或ip.To16()统一地址版本后再调用Contains。
net.IPNet.Contains 为什么返回 false，明明 IP 看起来在网段里？
常见原因是传入的 IP 没有标准化：IPv4 地址被表示为 16 字节（如 net.ParseIP("192.168.1.1") 返回的是 IPv4-mapped IPv6 格式），而 *net.IPNet 的 Contains 方法对字节长度敏感。如果子网是 IPv4（/24），但 IP 是 16 字节的 IPv6 形式，比较会失败。
解决办法是显式转成对应版本：
- 用
ip.To4()强制转 IPv4（返回nil表示不是合法 IPv4） - 或用
ip.To16()转 IPv6，再确保*net.IPNet也是 IPv6 网络 - 更稳妥的做法：先用
net.ParseCIDR("192.168.1.0/24")得到*net.IPNet，再对目标 IP 做.To4()判断
示例：
_, ipnet, _ := net.ParseCIDR("192.168.1.0/24")
ip := net.ParseIP("192.168.1.5")
if ipnet.Contains(ip.To4()) { // ✅ 必须 To4()
fmt.Println("in subnet")
}
IPv6 子网判断要特别注意地址长度和前缀格式
IPv6 的 Contains 要求 IP 和网络都使用 16 字节表示，且前缀长度必须匹配。常见坑是把 IPv4 地址误塞进 IPv6 网络判断，或者 CIDR 字符串写成 ::1/128 却传入 net.ParseIP("::1") —— 这个没问题，但若传入 net.ParseIP("127.0.0.1") 就永远返回 false。
实操建议：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- IPv6 网络请统一用
To16()处理 IP，避免混用To4() - 检查
IPNet.IP长度：len(ipnet.IP) == 16表示 IPv6，否则是 IPv4 - CIDR 字符串中不要省略双冒号展开（如
2001:db8::/32是合法的，但解析后IPNet.Mask.Size()才反映真实前缀长度）
net.IPNet.Contains 在边界 IP 上的行为是否可靠？
完全可靠。该方法底层调用的是按位与掩码比较，不依赖字符串解析或范围计算，因此网络地址（如 192.168.1.0）和广播地址（如 192.168.1.255）都会被正确包含在 192.168.1.0/24 中 —— 只要它们属于该子网的地址空间。
注意点：
-
Contains不区分“可用主机地址”和“网络/广播地址”，它只做数学意义上的包含判断 - 如果业务逻辑需要排除网络地址和广播地址，得额外用
ip.Equal(ipnet.IP)和ip.Equal(ipnet.Mask)（需先计算广播地址）手动过滤 - 子网掩码本身不影响
Contains逻辑，它只依赖IPNet.IP和IPNet.Mask两个字段
性能关键场景下，多次调用 Contains 是否有优化空间？
单次调用开销极小（纯位运算），但若需高频判断（如每秒万级请求），可预计算掩码和网络基址，避免重复解析 CIDR 或构造 *net.IPNet。
推荐做法：
- 把
*net.IPNet实例缓存复用，而不是每次调用都net.ParseCIDR - 对固定 IPv4 地址，可将
net.IP转为uint32，用整数位运算代替Contains（仅限 IPv4） - 不要自己重写
Contains逻辑 —— Go 标准库实现已高度优化，且处理了 IPv4/IPv6 兼容路径
真正容易被忽略的是：当子网来自用户输入时，net.ParseCIDR 可能失败，而 Contains 对 nil *net.IPNet panic；务必先校验解析结果非 nil 再调用。
