MAC地址需用pattern正则校验，推荐^([0-9A-Fa-f]{2}[:-]){5}[0-9A-Fa-f]{2}$，配合trim()、大小写转换及业务规则（如排除全零/广播地址）和后端双重验证。
input[type="text"] 无法原生校验 MAC 地址，浏览器没有 type="mac" 这种类型。必须靠 pattern 属性 + 正则，或 JavaScript 手动干预。
用 pattern 做基础前端拦截
这是最轻量、最符合 HTML5 原生验证逻辑的做法，但要注意正则写法和浏览器行为边界：
-
pattern只在表单提交时触发，不监听输入过程；用户可一直乱输，直到点提交才报错 - 正则必须严格匹配整个字符串，不能只写片段；推荐用：
^([0-9A-Fa-f]{2}[:-]){5}[0-9A-Fa-f]{2}$ - 不要加
g或m标志——pattern内部自动做全局/多行处理，加了反而失效 - 冒号和连字符不能混用，所以
00:1A-2B:3C-4D:5E会被拒绝，这是对的，不是 bug - 示例写法：
<input type="text" name="mac" pattern="^([0-9A-Fa-f]{2}[:-]){5}[0-9A-Fa-f]{2}$" title="请输入合法MAC地址，如 00:1A:2B:3C:4D:5E">
JavaScript 补位：解决 pattern 漏掉的常见坑
pattern 对大小写不敏感（浏览器自动转小写再匹配），但它拦不住这些真实场景问题：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 用户粘贴带首尾空格的 MAC（如
" 00:1A:2B:3C:4D:5E "）→ 提交前必须.trim() - 全零地址（
00:00:00:00:00:00）或广播地址（FF:FF:FF:FF:FF:FF）虽格式合法，但业务上通常无效 → 需额外判断 - 虚拟网卡地址（如 VMware 的
00:0C:29.*、VirtualBox 的08:00:27.*）是否允许，得看后端策略，前端最多 warn - 建议在
submit事件里统一处理：const mac = input.value.trim().toUpperCase(); if (/^([0-9A-F]{2}:){5}[0-9A-F]{2}$/.test(mac) && mac !== '00:00:00:00:00:00' && mac !== 'FF:FF:FF:FF:FF:FF') { /* 通过 */ }
别信 type="text" 的 placeholder 提示
placeholder 里写 “格式：XX:XX:XX:XX:XX:XX” 完全没校验作用，用户删掉它、填空格、填中文照样能点提交。真正起效的只有：
立即学习“前端免费学习笔记（深入）”；
-
required—— 拦空值，但拦不住纯空格 -
pattern—— 拦格式，但拦不住语义错误（比如 OUI 厂商码不存在） - JavaScript 中的
.trim()和显式正则 —— 拦粘贴失真和业务规则 - 后端再次校验 —— 因为所有前端校验都可绕过，MAC 地址最终必须由服务端用相同正则+OUI 数据库查证
真正容易被忽略的是：MAC 地址校验不是“格式对就完事”，而是“格式对 + 非保留地址 + 符合设备上下文”。比如 IoT 设备配网时，用户扫到的 MAC 往往是蓝牙广播里的，可能带前缀或截断，这时候光靠前端正则根本不可靠，得结合设备 SDK 返回的真实值做比对。
