Go netip.Prefix 为什么保留主机位而不是自动归零

很多人看到 192.0.2.129/24 时，会下意识把它理解成网络号 192.0.2.0/24。但在 Go 的 net/netip 中，netip.Prefix 同时保存地址和前缀长度，解析或构造时不会擅自替调用者清掉主机位。

所以答案很直接：如果业务需要“规范网络前缀”，就显式调用 Masked()；如果只是用 Contains 判断某个地址是否属于一段前缀，则使用查询方法，不要把 Addr() 的字符串表现当成网络号判断。

官方文档：https://pkg.go.dev/net/netip

先看两种来源为什么都可能保留主机位

ParsePrefix 负责解析 CIDR 文本，PrefixFrom 负责用一个地址和位数构造 Prefix。两者的共同点是：输入地址本身仍有意义，库不会替你猜测“现在一定要把它当作网络号”。尤其是 PrefixFrom 的输入可能来自主机地址，自动归零会隐藏调用者原来的地址信息。

这也是为什么下面两类代码都应该先明确意图：需要保留输入地址的语境时保留原 Prefix，需要网络号时再规范化。

用 Masked 得到规范网络前缀

把“解析”与“归一化”分开，代码的边界会更清楚。下面的示例只展示 API 关系：原始 Prefix 记录输入地址，Masked 返回掩码后的 Prefix，适合后续展示或作为稳定值保存。

package main

import (
    "fmt"
    "net/netip"
)

func main() {
    // 解析保留主机位的 CIDR 文本，不把它直接当作网络号。
    raw := netip.MustParsePrefix("192.0.2.129/24")

    // 只有在需要规范网络前缀时，才显式清除主机位。
    network := raw.Masked()

    fmt.Println("原始：", raw, raw.Addr(), raw.Bits())
    fmt.Println("规范：", network, network.Addr(), network.Bits())
}

这里的关键不是“哪一行更短”，而是把语义写出来：raw 表示输入，network 表示规范网络。两者的前缀长度可以相同，但地址部分的表达不同。

把规范化放在输入边界处

如果 Prefix 会进入缓存键、数据库字段、日志字段或配置比较，建议在边界处统一处理，而不是让每个调用者临时猜测是否已经掩码。

package main

import (
    "net/netip"
)

// canonicalPrefix 将外部 CIDR 输入统一成可稳定保存的网络前缀。
func canonicalPrefix(text string) (netip.Prefix, error) {
    // 先保留解析错误，避免把非法输入悄悄变成零值 Prefix。
    prefix, err := netip.ParsePrefix(text)
    if err != nil {
        return netip.Prefix{}, err
    }
    // 统一掩码后再交给缓存、比较或序列化层。
    return prefix.Masked(), nil
}

如果场景只是判断地址是否落在前缀内，应直接使用 prefix.Contains(addr)。如果场景是生成网络段名称、构造去重键或输出规范 CIDR，则先使用 Masked，这样调用方不会把“同一网络的不同主机地址”误当成不同网络。

兼容注意：不要把三个概念混成一个

最常见的误区是看到 /24 就默认地址已经是网络号，或者为了判断归属而手动比较字符串。前者忽略了 Prefix 的保存语义，后者绕开了标准库提供的查询方法。

总结与常见问题

Go netip.Prefix 保留主机位，是为了不替调用者猜测地址用途。解析、构造、规范化和归属查询是四件事：先用 ParsePrefix 或 PrefixFrom 得到对象，需要网络号时调用 Masked，需要判断归属时调用 Contains。

为什么 PrefixFrom 后还要 Masked？

因为 PrefixFrom 使用的是调用者提供的地址和位数，不默认替调用者清除主机位。把它用于网络段表示前先调用 Masked 即可。

所有场景都要先 Masked 吗？

不需要。只做 Contains 查询时直接使用 Prefix；只有需要规范网络号、稳定字符串或稳定键时，才把 Masked 放在边界处。