有个需求几乎隔一段时间就会出现一次判断一个字符串是不是合法的 IPv4 地址。听着很简单拆开一看就是四段数字每段 0 到 255用点分隔很多人第一反应就是写个正则完事。但真做过的朋友都知道这里面全是暗坑999.999.999.999这种一眼假的东西某些正则照样放行01.2.3.4算不算合法不同语言给的答案都不一样更别说紧跟其后的本地连接 IPv4 地址改不了这类用户报障——十有八九是往系统设置里填了一个格式非法的地址系统直接不给保存。这篇文章我就把这个判断函数从定义标准到实现细节、再到测试用例完整拆开聊一遍适合需要做表单校验、日志过滤、配置文件检查、网络工具链的开发同学参考。1. 这个判断为什么不是简单调个正则的问题1.1 那些年被一眼就能匹配的正则坑过的人先说一个我经常见到的写法/^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$/这个正则看起来很合理但它只检查了是不是四段数字完全没有检查数字的数值范围。于是999.999.999.999、345.12.1.1全部通过。同事拿着这个正则去校验用户输入的网络参数然后线上就出现了网关配置被写成了一个完全不可路由的地址。要修这个问题常见的补救是把正则写细import re pattern re.compile( r^(?:(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)\.){3} r(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)$ )这个正则把 0 到 255 拆成了几个片段25[0-5]覆盖 250-2552[0-4]\d覆盖 200-2491\d\d覆盖 100-199[1-9]?\d覆盖 0-99。它能在绝大多数情况下给出正确结果也确实更快——正则引擎线性扫描一遍就出结果。但正则有一个副作用[1-9]?\d这一段会接受01和09。因为它允许十位不出现然后个位匹配1或9。如果你只要求数值上合法01当然没问题因为01解析出来就是1。可如果你遵守 RFC 3986 里对 IPv4 地址实体的定义——十进制数字段不允许前导零——那这个正则就过宽了。如果你要严格拒绝前导零正则得改成下面这样pattern re.compile( r^(?:0|[1-9]\d?|1\d\d|2[0-4]\d|25[0-5]) r(?:\.(?:0|[1-9]\d?|1\d\d|2[0-4]\d|25[0-5])){3}$ )这里的思想是0单独拎出来其余的必须以[1-9]开头后面最多再跟两位数字。代价是正则的可读性进一步下降——代码评审时大概率会有人问这到底在干嘛。1.2 各语言自带解析库的行为也不一致更麻烦的是不同语言自带的 IP 解析函数对同一个字符串给的判定结果可能完全不同。我用几个最常见环境举个例子Python 的socket.inet_aton(01.2.3.4)不仅会接受这个字符串还会将前导零按八进制解释得到实际上是1.2.3.4的二进制数据。这就是历史上某些 C 库函数的行为惯性。Python 的ipaddress.ip_address(01.2.3.4)则直接抛异常它在较新的版本里明确拒绝前导零。Go 的net.ParseIP能接受::ffff:1.2.3.4这种 IPv4 映射 IPv6 的写法并返回一个 16 字节的 IP 对象如果你的代码没有显式检查To4()是否为空就会把一段 IPv6 字面量当成了 IPv4。浏览器里的new URL(http://192.168.1.1\n)在某些版本里是能正常解析的末尾换行会被自动忽略这在做前端校验时会出大问题。这就引出了第一个核心观点判断字符串是否为有效 IPv4 地址其实没有一个绝对的答案答案取决于你先把有效两个字定义到多严格。项目里写函数之前一定要先跟团队对齐规矩允不允许前导零、允不允许首尾空白、允不允许 IPv4 映射 IPv6、允不允许 CIDR 后缀。规矩不对齐写出来的函数测试用例都凑不齐。2. 先立规范什么才算有效IPv4地址2.1 格式规则四段、十进制、0-255、无不该有的符号我建议把格式合法和语义可用分开。先定格式规则再谈网络语义。格式层面一份能被绝大多数项目接受的规则如下必须恰好四段不多不少段之间用英文半角点号.分隔。每段必须是非空字符串且全部由 ASCII 数字字符组成不允许正负号、空格、小数点以外的任何符号。每段转成十进制整数后必须在 0 到 255 之间。不允许前导零除非这个段本身就是0。也就是说0.0.0.0合法01.2.3.4不合法。不允许首尾有多余空白函数内部可以trim之后再做判定判定对象应当是整理后的字符串而不是用户原始输入。不允许出现192.168.1.0/24这种 CIDR 写法不允许192.168.1.1:8080这种带端口写法它们属于包含 IP 地址的字符串但不是纯 IPv4 地址本身。为什么要拒绝前导零一方面 RFC 3986 的 ABNF 定义里十进制段就是0或首位非零的数字组合前导零不是标准写法另一方面在安全审查里拒绝前导零、拒绝八进制写法是防止绕过 IP 黑名单的常见手段。比如你的防火墙规则里封禁了1.2.3.4结果某个旧解析器把1.2.3.4前面那个段写成01就解析成了同一个地址但匹配不上你的封禁列表这种绕过很容易引发问题。严格的字符串校验函数应该把这些写法直接挡在门外。2.2 三个容易扯皮的分界点前导零、空白符、IPv4映射IPv6把规则明确了之后你会发现 90% 的争论都发生在三个分界点前导零。上面已经展开过。我的建议是默认拒绝除非你的业务明确要求兼容老式 C 解析器的行为。首尾空白。有些人觉得 192.168.1.1 应该判合法因为用户手滑加个空格是常有的事有些人觉得必须严格。这里没有对错但要明确最好在函数入口统一strip然后对外文档写明函数接受经过去除首尾空白后的字符串。IPv4 映射 IPv6。::ffff:192.168.1.1是一种特殊写法Go 的net.ParseIP会返回一个 IP 对象你在调To4()的时候似乎能拿到 4 字节数据。但它本质上是一个 IPv6 字面量不是一串纯 IPv4 点分十进制的字符串。如果判断函数的输入来自用户手动输入或配置文件我倾向于直接拒绝这种形式。把这三个点写进文档而不是留在口头沟通里是每个做底层工具的人都应该养成的习惯。判断函数本身的代码并不复杂复杂的是让所有调用方理解这个函数的边界。3. 三种实现路线正则、逐段解析、混合双保险3.1 正则方案写法与性能的红利、可维护性的代价正则方案最大的优势是代码短、逻辑集中、性能稳定。一个编译好的正则对常见输入长度15 个字符左右的判断开销非常小拿来跑海量日志过滤也没压力。但正则的劣势一样明显可读性差非正则熟练的同事很难 review不好扩展比如你想额外把每段截出来做广播地址判断、私有地址判断正则匹配完还得再拆一次。如果执意用纯正则建议用下面这个严格版拒绝前导零、拒绝超范围STRICT_IPV4_RE re.compile( r^(?:0|[1-9]\d?|1\d\d|2[0-4]\d|25[0-5]) r(?:\.(?:0|[1-9]\d?|1\d\d|2[0-4]\d|25[0-5])){3}$ ) def is_valid_ipv4_v1(s: str) - bool: if not isinstance(s, str): return False return bool(STRICT_IPV4_RE.match(s.strip()))这里match本身要求从字符串开头匹配配合$锚定结尾可以保证整个字符串都必须被正则覆盖不存在前面匹配了后面还有尾巴的问题。注意re.match是从开头找如果不用^也没关系但用了^语义更明确。3.2 逐段解析方案最容易掌控细节的做法如果不依赖正则手写逐段解析会让整个判断过程完全透明。核心流程只有四步去掉首尾空白、按点号拆分、逐段检查、最后拼起来看段数。def is_valid_ipv4_v2(s: str) - bool: if not isinstance(s, str): return False s s.strip() parts s.split(.) # 这一步关键拆分后必须是 4 段不多不少 if len(parts) ! 4: return False for p in parts: if len(p) 0 or len(p) 3: return False if p[0] 0 and len(p) 1: return False # 拒绝前导零 for ch in p: if ch 0 or ch 9: return False if int(p) 255: return False return True为什么要在拆分后检查len(p) 3因为长度超过 3 的数字段无论数值多大都必然超过 255。比如0000000000000001虽然数值是 1但格式上完全不像 IPv4 地址的一部分而且这么写还有让某些老解析器产生歧义的隐患。为什么每段要逐个字符判断是不是0到9因为很多语言里的字符数字判断比如 Python 的isdigit()会把一些 Unicode 数字也判为真例如全角数字、上标数字等。这些字符放进 IP 地址里属于胡闹但用isdigit会误放行。逐字符按 ASCII 范围判断虽然啰嗦却彻底杜绝了这类问题。手写解析的另一个好处是到了下一步你还想判断这是不是私有地址、这是不是广播地址parts数组里的四段数值已经现成直接拿去用就行不需要二次 split。3.3 混合方案与标准库的取舍实际项目里我经常采用的是一种折中先用一个非常宽松的正则只检查看起来像四段数字做粗筛再用手写逻辑做数值检查。这么做的好处是——粗筛负责把明显不合格的字符串快速挡掉后面的数值检查则保证了语义位置的明确性代码读起来比一段密集正则容易得多。import re LOOSE_IPV4_RE re.compile( r^(?:\d{1,3}\.){3}\d{1,3}$ ) def is_valid_ipv4_v3(s: str) - bool: if not isinstance(s, str): return False s s.strip() if not LOOSE_IPV4_RE.match(s): return False parts s.split(.) for p in parts: if p[0] 0 and len(p) 1: return False if int(p) 255: return False return True很多语言自带的标准库能不能直接用能用但要先确认它的行为边界。Python 的ipaddress.ip_address是严格派前导零直接抛异常这点很好但它要求你捕获ValueError而且它返回的是一个对象而不是布尔值有些调用方不喜欢这种接口。Go 的net.ParseIP上文已经提过它对 IPv4 映射 IPv6 的写法过于宽容如果你在写防火墙规则校验必须额外判断返回值是不是 4 字节的形式。JavaScript 的标准库没有内置 IPv4 校验大家基本都落到了手写或正则上。所以我的真实推荐是如果判断结果要用于安全过滤或系统配置不要只依赖语言内置解析库更不要只依赖宽松正则。用混合方案逻辑自己掌控边界写在注释和测试里。另外补一个 JavaScript 版混合实现方便做前端校验的朋友直接抄function isValidIPv4(str) { if (typeof str ! string) return false; const s str.trim(); const parts s.split(.); if (parts.length ! 4) return false; for (const p of parts) { if (p.length 0 || p.length 3) return false; if (p[0] 0 p.length 1) return false; if (!/^\d$/.test(p)) return false; const num Number(p); if (num 0 || num 255) return false; } return true; }Go 的实现也不难注意用strings.Split后先验段数import strings func IsValidIPv4(s string) bool { parts : strings.Split(strings.TrimSpace(s), .) if len(parts) ! 4 { return false } for _, p : range parts { if len(p) 0 || len(p) 3 { return false } num : 0 for i : 0; i len(p); i { c : p[i] if c 0 || c 9 { return false } num num*10 int(c-0) } if (len(p) 1 p[0] 0) || num 255 { return false } } return true }4. 边界情况实测与决策记录4.1 一张表看尽日常会遇到的所有输入我每次写这个函数都会在注释里留一张测试用例表方便后来人理解哪些输入是被故意拒绝的。这里直接列一份输入判定说明192.168.1.1合法最常见的正常地址255.255.255.255合法广播地址格式上没问题0.0.0.0合法全零地址格式上没问题1.2.3非法只有三段1.2.3.4.5非法五段256.1.1.1非法首段超范围1.256.1.1非法任意一段超范围都不行01.2.3.4非法按严格规则拒绝前导零001.2.3.4非法多个前导零更不必说1.2..3.4非法中间有空段.1.2.3.4非法开头是点号split 后第一段是空字符串1.2.3.4.非法结尾是点号split 后多出一个空字符串1.2.3.a非法含字母1.2.3.4a非法数字后面跟字母1.2.3.-4非法带负号1.2.3.4:8080非法这是带端口的形式192.168.1.0/24非法这是 CIDR 表示法::ffff:192.168.1.1非法IPv4 映射 IPv6192.168.1.1/192.168.1.1合法先 trim函数内部统一处理首尾空白这张表右边的说明栏其实就是在定义你项目的校验语义。如果你的产品允许用户带端口或 CIDR 输入那你应该拆成两个字段一个IP 地址字段一个端口/前缀字段而不是让校验函数去放宽标准。4.2 全角字符与不可见空白从 Excel/PDF 复制来的 IP这个坑特别值得单独拿出来讲。用户经常从 Excel、PDF、聊天工具里复制 IP 地址复制出来的字符串里可能藏着全角点号看起来和.几乎一样但 ASCII 码完全不同split(.)之后整个字符串还是完整的一段。不间断空格或零宽空格肉眼完全不可见但会破坏校验。圆点周围有不可见字符比如192.168.1.1中间混入了 U200B。我自己处理过一例用户反馈 IP 输入框总是提示格式错误的问题最后把用户输入 dump 出来看十六进制才发现两个分隔点里有一个是全角点。从那以后我写这类校验功能时都会在前端做一次提示优化把常见的全角点、全角数字、空白字符在提交前自动替换掉替换完之后再进入校验函数。这样用户不用自己排查看不见的字符体验会好很多。4.3 trim 时机的坑末尾换行被解析库悄悄接受还有一个容易被忽略的细节是 trim 的时机。前面提到过某些浏览器环境或网络库在解析 URL 时会自动忽略输入末尾的换行。这带来的结果是同一个字符串192.168.1.1\n在你自己的校验函数里被判定非法但在后续某个网络请求环节却被悄悄接受并正常发送。这种前后不一致非常隐蔽排查起来也费劲。我的做法是校验函数入口统一先trim让所有调用方对齐同一个视觉上正常的输入样本。前端输入框先 trim 再校验后端接口如果收到trim后变了一个字符串的输入要么直接拒绝要么修完再校验。统一规则后至少不会出现前端说非法、后端说合法这种对峙局面。5. 判断函数在真实项目中的延伸5.1 回答格式是否合法之后还要回答语义能不能用做网络工具的人都知道格式合法的 IPv4 地址和能实际使用的 IPv4 地址是两码事。255.255.255.255格式上完全合法但它是一个受限广播地址通常不能作为普通主机的源地址。0.0.0.0也合法但它的语义是本机/任意地址在配置服务器监听地址时可能会有特殊解释。所以在判断函数之外我通常还会提供一组语义判断工具函数给上层业务按需组合def is_private_ipv4(ip_str: str) - bool: 判断是否为私有地址私有网段10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 if not is_valid_ipv4_v3(ip_str): return False a, b, _, _ map(int, ip_str.split(.)) return ( a 10 or (a 172 and 16 b 31) or (a 192 and b 168) ) def is_loopback_ipv4(ip_str: str) - bool: 回环地址127.0.0.0/8 if not is_valid_ipv4_v3(ip_str): return False return ip_str.split(.)[0] 127 def is_multicast_ipv4(ip_str: str) - bool: 组播地址224.0.0.0/4即 224~239 开头 if not is_valid_ipv4_v3(ip_str): return False first int(ip_str.split(.)[0]) return 224 first 239注意这些函数的输入应当来自已经通过格式校验的字符串所以我在函数内部依然复用了is_valid_ipv4_v3确保即使上层代码传入了原始用户输入也不会越界。很多时候判断 IP 是否合法只是链路的第一环后面还需要配合网络号、前缀长度做更复杂的子网归属判断把格式校验函数和语义判断函数拆开后面的扩展才能插得进来。5.2 从字符串校验到用户配置排查本地网络设置这类场景聊一个和本地连接 IPv4 地址改不了相关的现实场景。普通用户配置静态 IP 时系统会要求填四段数字常见报错其实是掩码和网关格式不对。我们在实际排障时遇到过几种用户把 IP 填成192.168.1.1/24系统不认因为输入框只接受纯地址。用户从某个文档复制了192.168.001.1有的系统会拒绝有的系统虽然不拒绝但保存后再打开显示成192.168.1.1容易引起困惑。用户填了192.168.1.256这个错误最有代表性——前三段都在常见私有网段范围最后一段 256 明显超界不校验根本发现不了。如果你在做一个网络配置工具里面就非常需要一个严格版的 IP 校验函数并且把错误提示写得明确一点不仅说格式错误最好能告诉用户是哪一段、超出范围多少。在这个层面上判断字符串是否为有效 IPv4 地址就不再是一道练习题而是一个实打实能帮用户解决问题的组件。6. 测试用例设计与回归要点6.1 一组可以直接抄走的测例判断函数再简单也必须有测试覆盖因为它被调用的频次通常很高而且很容易在后续改动中被踩坏。下面这组 Python 测试用例基本把常见的正常、异常情况都覆盖了可以直接放进项目里import pytest pytest.mark.parametrize(ip, [ 192.168.1.1, 255.255.255.255, 0.0.0.0, 10.0.0.1, 172.16.1.1, 8.8.8.8 , # trim 后合法 ]) def test_valid_ipv4(ip): assert is_valid_ipv4_v3(ip) is True pytest.mark.parametrize(ip, [ , # 空字符串 1.2.3, # 少一段 1.2.3.4.5, # 多一段 256.1.1.1, # 超上限 1.256.1.1, 1.1.1.256, 01.2.3.4, # 前导零 1.2.3.4 if isinstance(is_valid_ipv4_v3, type(lambda: None)) else 1.2.3.4, .1.2.3.4, 1.2.3.4., 1.2.3.a, 1.2.3.4a, 1.2.3.-4, 1e2.3.4.5, 192.168.1.1:8080, 192.168.1.0/24, ::ffff:192.168.1.1, ]) def test_invalid_ipv4(ip): assert is_valid_ipv4_v3(ip) is False注意上面那个奇怪的1.2.3.4用例我本意是想测末尾空格 trim 后合法但同一个用例如果出现在非法列表里就会跟合法用例冲突。正确的做法是把包含首尾空白的地址单独放到合法列表里测因为我们的函数统一做了trim。测试用例的名字和分组本身就是一种文档能把校验语义表达得很清楚。6.2 我踩过的三个回归坑最后分享几个我实际踩过的回归坑踩完之后才知道这些小函数改起来有多容易出问题。第一个坑一开始用isdigit()判断数字段后来某个输入里出现全角数字isdigit()返回 True导致全角数字通过了前两步校验直到int()转换时才报错。从那以后我坚持用ch 0 or ch 9判断不碰 Unicode 数字语义。第二个坑某次重构为了简化代码把is_valid_ipv4_v3改成了纯正则版本结果漏掉了len(parts) ! 4的原始保护导致1.2.3.4.5.6也被放行。后来我把段数必须为 4这一条固化成第一个断言任何实现方案都不能绕过它。第三个坑前端为了追求体验在输入框里直接过滤了非数字和点的字符结果全角点被当成非法字符直接删掉用户输入192.1681.1变成192.1681.1反而更乱。后来改为输入时不拦截提交时才统一提示和清洗用户体验反而更稳。如果你在自己的项目里也维护着这个看似不起眼的判断函数我强烈建议把上面的边界用例和策略整理进注释和测试里。这个函数不会成为你代码库里最亮眼的部分但它会在日志过滤、表单校验、防火墙规则检查等大量场景中被反复调用。把标准和边界写清楚一次写好后面所有人都会感谢你。