HTML表单中pattern属性可校验子网掩码格式，如^(255.){0,3}(255|254|252|248|240|224|192|128|0)(.(0|255|254|252|248|240|224|192|128|0)){0,3}$，但无法验证二进制连续性，必须依赖后端位运算校验。
HTML表单里直接用 pattern 属性校验子网掩码
HTML5 的 <input> 支持 pattern 属性，它接受一个正则表达式（不带 /g 标志），浏览器会在提交前自动校验。但注意：这个正则只做格式初筛，**无法判断“255.255.254.0”是否合法（它不是连续1+连续0）**，只能拦住明显错的如 256.0.0.0 或 255.0.255.0。
推荐用这个更严谨的 pattern：
^(255\.){0,3}(255|254|252|248|240|224|192|128|0)(\.(0|255|254|252|248|240|224|192|128|0)){0,3}$
它能覆盖所有标准子网掩码十进制值（含 0.0.0.0 和 255.255.255.255），但依然不检查二进制连续性 —— 这是浏览器原生 pattern 的硬限制。
为什么不能只用通用 IP 正则校验子网掩码
常见误区是复用 IPv4 格式正则，比如：
立即学习“前端免费学习笔记（深入）”；
^((25[0-5]|2[0-4]\d|[01]?\d\d?)\.){3}(25[0-5]|2[0-4]\d|[01]?\d\d?)$
这个会放行 255.255.255.1、255.255.128.128 等非法掩码，因为它们虽是合法 IPv4 地址，但二进制中 1 和 0 交替出现，不符合子网掩码定义。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
255.255.255.1→11111111.11111111.11111111.00000001：末尾 1 后跟 0，再跟 1 → 连续性破坏 -
255.255.128.128→ 第三段10000000后接第四段10000000，中间无连续 0 区域
所以必须限定每段只取 CIDR 允许的值：0、128、192、224、240、248、252、254、255。
前端校验后仍需后端二次验证
pattern 只在用户提交时触发，且可被绕过（禁用 JS、手动改 DOM、curl 提交）。真正可靠的校验必须在服务端完成，例如 Java 中：
- 先用正则快速过滤格式错误
- 再将四段转为整数，逐段计算
num & (num + 1)—— 若结果非 0，说明该段二进制含孤立 1，即不满足“全 1 前缀 + 全 0 后缀” - 最后检查整体 32 位中 1 的总数是否为 0/8/16/24/32（对应 /0 到 /32）
典型错误写法：Integer.bitCount(num) 单独算每段 1 的个数 —— 这会把 128（10000000）和 192（11000000）都判为合法，但没保证段间连续性；必须拼成完整 32 位再校验。
实际部署时容易漏掉的边界情况
真实网络配置中会遇到这些边缘输入，pattern 很难覆盖，必须靠后端逻辑兜底：
-
0.0.0.0：合法（/0），但有些旧正则会因开头0.被误判 -
255.255.255.255：非法（无主机位），但格式上符合 pattern，需单独排除 - 全零段后的非零段，如
255.255.0.128：第三段为 0，第四段非 0 → 二进制中断，必须拒绝 - 多余空格或换行：HTML 表单默认不 trim，
" 255.255.255.0 "会被 pattern 拒绝，应先.trim()
最终建议：前端 pattern 仅作友好提示，核心逻辑永远落在服务端；别试图用一个正则解决所有问题 —— 子网掩码的本质是位运算约束，不是字符串模式匹配。
