最可靠的方式是直接调用 net.parsemac，它校验格式、长度和字符范围，支持多种分隔符且不区分大小写，但需额外检查 len(mac) == 6 以限定为 6 字节以太网 mac。
用 net.ParseMAC 判断 MAC 地址合法性最可靠
直接调用 net.ParseMAC 是 Golang 官方推荐方式，它不仅校验格式，还验证长度和字符范围。返回 nil 错误即表示非法。
- 支持常见分隔符：冒号（
:）、短横线（-）、点（.），如"00:11:22:33:44:55"、"00-11-22-33-44-55"、"0011.2233.4455" - 不区分大小写，
"AA:BB:CC:DD:EE:FF"和"aa:bb:cc:dd:ee:ff"都合法 - 会拒绝带空格、多余分隔符或非十六进制字符的字符串，比如
"00:11:22:33:44:5G"或"00:11::22:33:44:55" - 注意：
net.ParseMAC对 6 字节 MAC（以太网）和 8 字节 MAC（如某些 IEEE 802.11 扩展）都接受，若业务只允许 6 字节，需额外检查len(mac)是否等于 6
手动正则匹配容易漏掉边界情况
正则看似简单，但 MAC 地址格式变种多，自己写容易出错。例如只匹配 xx:xx:xx:xx:xx:xx 会漏掉 xxxx.xxxx.xxxx 格式；忽略大小写处理或允许前导零超长也会引入误判。
PyCharm 2026.2.0.1 Mac版
下载
PyCharm 2026.2.0.1 Mac版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合在macOS系统上进行 Python 项目开发、运行、调试和测试。
- 常见错误正则：
^[a-fA-F0-9]{2}(:[a-fA-F0-9]{2}){5}$—— 只覆盖冒号分隔，且未限制总长度（"000:11:22:33:44:55"中第一个字段超长却可能被接受） - 更稳妥的手动校验要先按分隔符切分，再逐段验证是否为 2 位十六进制，最后确认段数和每段长度，代码量和维护成本远高于
net.ParseMAC - 除非有特殊需求（如必须在无
net包环境下运行），否则不建议绕过标准库
注意 net.ParseMAC 的隐含行为：自动归一化与空格容忍
net.ParseMAC 会对输入做一定预处理，这既是便利也是陷阱。
- 它会忽略字符串首尾空白，所以
" 00:11:22:33:44:55 "能通过 - 但不会忽略中间空白：
"00:11: 22:33:44:55"会失败，报错"invalid MAC address" - 返回的
net.HardwareAddr是字节切片，内容已归一化（全小写、无分隔符），若你只需要判断合法性，不必关心返回值内容 - 如果业务要求严格禁止首尾空格，得先用
strings.TrimSpace比对原始字符串，再传给net.ParseMAC
性能差异微乎其微，别为“避免分配”过早优化
有人担心 net.ParseMAC 内部会分配内存或做多余转换，影响高频校验性能。实测在现代 Go 版本（1.19+）中，单次调用开销约 20–50 ns，比手写正则还略快；且标准库实现已针对常见格式做了路径优化。
- 基准测试显示，对合法地址，
net.ParseMAC比编译好的正则快 10%–20% - 对非法地址，两者差距不大，但
net.ParseMAC错误信息更明确（"invalid MAC address"），便于调试 - 真正影响性能的是反复编译正则（每次调用都
regexp.Compile），而标准库无此问题
_, err := net.ParseMAC(s)，然后判断 err != nil。最容易被忽略的是——它接受 8 字节 MAC，如果你的系统只认 6 字节以太网地址，必须显式加 len(mac) == 6 判断。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
