Go netip.Addr 怎样替代字符串比较 IP

如果把 IP 地址当字符串比较，代码看起来简单，结果却可能很快偏离直觉："10.0.0.2" 和 "10.0.0.11" 的字典序不是数值顺序，IPv6 还会遇到大小写、零压缩和 IPv4-mapped IPv6 的写法差异。更稳妥的做法是先用 netip.ParseAddr 把输入变成 netip.Addr，再按任务选择 ==、Compare 或 Less。

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

我会用一个“请求来源是否在允许列表”的场景来拆开这件事：解析失败先返回错误；同一个地址用 == 判断；需要排序用 Less；只有在确实要统一 IPv4-mapped IPv6 或 zone 语义时，才显式做归一化。

先把字符串转换成可比较的 Addr 值

字符串比较的问题不只是格式不统一，还把“地址是否合法”和“地址是否相同”混成了一个问题。netip.ParseAddr 接受点分十进制 IPv4、IPv6，以及带 scoped addressing zone 的 IPv6；成功后返回一个不可变的值类型。解析错误不能被吞掉，否则返回的零值可能被误当作一个普通地址继续流转。

以白名单判断为例，可以把“解析一次”放在输入边界，而不是每次比较时都重新转换：

package main

import (
	"fmt"
	"net/netip"
)

// sameIP 只比较两个合法的 IP 值；任意一侧解析失败都返回错误。
func sameIP(leftText, rightText string) (bool, error) {
	left, err := netip.ParseAddr(leftText)
	if err != nil {
		return false, fmt.Errorf("解析左侧 IP: %w", err)
	}
	right, err := netip.ParseAddr(rightText)
	if err != nil {
		return false, fmt.Errorf("解析右侧 IP: %w", err)
	}
	// Addr 是可比较值；这里比较的是地址语义，不是原始字符串。
	return left == right, nil
}

这里没有调用 DNS，也没有把主机名当成 IP 解析。对于来自 HTTP 头、配置文件或数据库的文本，先在边界处完成解析，后面的业务函数就可以接收 netip.Addr，减少重复解析和格式分支。

用 ==、Compare 和 Less 替代字符串运算

经过解析之后，选择哪个方法取决于问题本身，而不是为了“看起来更专业”：

比如允许列表已经在启动阶段解析完成，处理请求时只需解析来访地址并查表：

package main

import "net/netip"

// buildAllowlist 把配置文本转换为稳定的 Addr 键；坏配置直接暴露给启动流程。
func buildAllowlist(values []string) (map[netip.Addr]bool, error) {
	allow := make(map[netip.Addr]bool, len(values))
	for _, text := range values {
		addr, err := netip.ParseAddr(text)
		if err != nil {
			return nil, err
		}
		// map 的键是 Addr，不会保留同一地址的不同文本写法。
		allow[addr] = true
	}
	return allow, nil
}

// allowed 判断请求地址是否命中已解析的允许列表。
func allowed(allow map[netip.Addr]bool, requestText string) (bool, error) {
	requestAddr, err := netip.ParseAddr(requestText)
	if err != nil {
		return false, err
	}
	return allow[requestAddr], nil
}

Compare 的结果适合传给需要三值关系的逻辑；Less 则直接对应排序谓词。官方定义的排序先按地址长度，再按地址值；IPv6 zone 也会影响排序位置，所以不要把它理解成业务上的“网络距离”或权限等级。

IPv4-mapped IPv6 和 zone 要不要统一

有一个很容易被忽略的边界：192.0.2.1 是 IPv4，而 ::ffff:192.0.2.1 是 IPv4-mapped IPv6。它们在某些业务里表示同一个终端，但在 netip.Addr 的地址族语义里不是自动相等的两个值。此时可以在业务明确要求“按裸 IPv4 身份比较”时调用 Unmap：

package main

import "net/netip"

// sameEndpointIP 只在业务定义允许时折叠 IPv4-mapped IPv6。
func sameEndpointIP(leftText, rightText string) (bool, error) {
	left, err := netip.ParseAddr(leftText)
	if err != nil {
		return false, err
	}
	right, err := netip.ParseAddr(rightText)
	if err != nil {
		return false, err
	}
	// Unmap 不会把普通 IPv6 改成 IPv4；它只移除映射前缀。
	return left.Unmap() == right.Unmap(), nil
}

IPv6 zone 也不能随意删掉。fe80::1%eth0 和 fe80::1%en0 可能指向不同接口；如果业务只关心地址本体、明确不关心接口，再用 WithZone("") 去除 zone。这个动作是领域规则，不是所有网络判断都应该默认做的归一化。

另外，netip.Addr{} 是无效零值，不等于 0.0.0.0 或 ::。比较前先检查解析错误，必要时用 IsValid 检查值是否已初始化。

把解析、比较和输出放在正确的边界

我的取舍是：文本只在输入边界出现一次，业务层尽量传递 netip.Addr。需要日志或响应时再调用 String 生成规范化文本；需要排序时使用 Less；需要集合命中时用 map[netip.Addr]bool。这样既避免了字符串格式差异，也让代码直接表达意图。

但 netip.Addr 不是安全策略本身。IsPrivate 等分类方法不能单独代替访问控制；IP 可能来自代理头、连接对端或应用层字段，信任哪个来源仍需要由协议和部署边界决定。把字符串换成值类型，解决的是表示和比较问题，不会自动解决来源伪造问题。

为什么不直接比较 String()

String 适合展示、日志和序列化；比较时已经拥有 Addr 就直接比较值。把值重新格式化为字符串再比较，相当于绕回文本层，还会让 zone 和映射地址的业务规则变得不明显。

比较顺序能代表 IP 的网络先后吗

不能把 Less 当作路由匹配、网段包含或网络距离判断。它提供稳定的排序关系；如果任务是判断某个 IP 是否落在网段内，应使用 netip.Prefix 相关能力单独表达。

什么时候还可以保留原始字符串

审计、回显和排查时可以同时保存原始输入与解析后的 Addr：原始文本帮助追溯输入，Addr 负责比较和键控。两者职责不同，不必强行只保留一种。

最终可以记住一条边界：ParseAddr 负责把文本变成地址值，== 负责相等，Compare 负责三值关系，Less 负责排序；Unmap 和 WithZone("") 只有在业务明确需要时才使用。这样替代字符串比较，解决的是“同一地址不应被写法差异干扰”，而不是把所有网络语义都压成一个通用判断。