可测的IP限流核心是将IP判断逻辑抽为纯函数IsAllowedIP，只接收string类型IP并返回bool和error，黑白名单通过参数传入；需分离IPv4/IPv6网段处理，统一解析单IP与CIDR，测试时用httptest模拟请求链路。
怎么用 Go 写可测的 IP 限流/过滤逻辑
核心是把 IP 判断逻辑从 HTTP 处理器里剥出来，做成纯函数。否则你每次测都要起 server、构造 request、mock net.Conn——还没开始写断言，环境就崩了。
实操建议：IsAllowedIP 这类函数只接收 string（IP 地址），返回 bool 和可选错误；黑白名单数据通过参数传入，别读配置文件或全局变量。
- 常见错误：在
http.HandlerFunc里直接调用net.ParseIP(r.RemoteAddr)后立刻判断，导致无法对解析后的 IP 做单元测试 - 正确做法：把
net.ParseIP提前到测试用例里，传入标准格式的 IPv4/IPv6 字符串（如"192.168.1.100"或"2001:db8::1"） - 注意：Go 的
net.ParseIP对带端口的"192.168.1.100:8080"返回 nil，测试时得先用strings.Split截掉:后面部分
IPv4 和 IPv6 的匹配要分开处理
用 net.IP 做 Contains 判断时，net.IPNet 对 IPv4 和 IPv6 是严格区分的。一个 /24 的 IPv4 网段不会匹配 IPv6 地址，反之亦然——但人容易忽略这点，尤其本地测试常用 ::1 或 127.0.0.1 混着来。
实操建议：黑白名单结构体里，把 IPv4 和 IPv6 的网段列表分开存，比如：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
type IPFilter struct {
allowV4 []*net.IPNet
allowV6 []*net.IPNet
denyV4 []*net.IPNet
denyV6 []*net.IPNet
}
- 常见错误：把
"::1/128"解析成*net.IPNet后，拿它去 match"127.0.0.1"，结果永远 false，但没报错，逻辑静默失效 - 使用场景：测试时显式构造两类网段，例如用
mustParseCIDR("192.168.0.0/16")和mustParseCIDR("2001:db8::/32") -
mustParseCIDR是个辅助函数，内部用net.ParseCIDR，panic 代替 error 返回——测试里可以接受，生产代码别这么干
测试 CIDR 和单 IP 的边界情况
黑白名单不只含网段，还常包含单个 IP（如 "10.0.0.5"）。但 net.ParseCIDR("10.0.0.5") 会失败，必须补成 "10.0.0.5/32"；而用户输入可能带或不带 /32，得统一处理。
实操建议：写个 ParseIPOrCIDR 函数，优先按 CIDR 解析，失败则当单 IP 处理并补掩码：
func ParseIPOrCIDR(s string) (*net.IPNet, error) {
if _, net, err := net.ParseCIDR(s); err == nil {
return net, nil
}
ip := net.ParseIP(s)
if ip == nil {
return nil, fmt.Errorf("invalid IP or CIDR: %s", s)
}
mask := net.CIDRMask(32, 32)
if ip.To4() == nil {
mask = net.CIDRMask(128, 128)
}
return &net.IPNet{IP: ip, Mask: mask}, nil
}
- 常见错误：直接用
net.ParseIP得到net.IP，然后试图调用ipNet.Contains(ip)—— 不行，Contains是*net.IPNet的方法，不是net.IP的 - 性能影响：每次请求都调用
ParseIPOrCIDR有开销，但测试中无所谓；生产环境应预解析好所有规则，运行时只做Contains判断 - 容易漏：IPv6 单 IP 补的是
/128掩码，不是/32，net.IP.To4()为 nil 时就得切分支
测试里怎么模拟真实请求链路
光测 IsAllowedIP 不够，得验证它和中间件、HTTP handler 串起来是否真生效。这时候不用起完整 server，用 httptest.NewRequest + httptest.NewRecorder 就够。
实操建议：写一个最小闭环测试，例如：
req := httptest.NewRequest("GET", "/api/data", nil)
req.RemoteAddr = "192.168.1.200:12345"
rr := httptest.NewRecorder()
handler := IPFilterMiddleware(allowList)(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(200)
}))
handler.ServeHTTP(rr, req)
- 常见错误：忘了设
req.RemoteAddr，默认是"127.0.0.1:0"，结果所有测试都走默认分支 - 注意：Go 的
httptest.NewRequest不解析RemoteAddr，它只是字符串字段，你的中间件得自己调strings.Split(req.RemoteAddr, ":")取 IP 部分 - 兼容性影响：某些代理（如 Nginx）会把真实 IP 放在
X-Forwarded-For，这时RemoteAddr是代理地址。测试这类场景，得额外加 header 并修改中间件逻辑——别等上线才发现没覆盖
真正难的不是写判断逻辑，是把「谁提供 IP」「谁决定用哪个字段」「网段解析容错」这些细节，在测试里一条条钉死。漏一个，线上就可能放行不该放的 IP，或者拦住合法流量。
