不能只用一个正则完美验证邮箱，因为RFC 5322定义的合法邮箱格式极其复杂（如"Abc@def"@example.com），而实际系统几乎不支持；Go标准库net/mail.ParseAddress语法解析更可靠，应作为基础校验，再叠加业务约束。
为什么不能只用一个正则完美验证邮箱
直接说结论：Go 标准库 net/mail 解析比正则更可靠，而「合法邮箱」本身没有唯一标准——RFC 5322 允许的格式极其复杂（比如 "Abc@def"@example.com 是合法的），实际项目中几乎没人接受这种写法。所以生产环境应优先用 mail.ParseAddress 做基础解析，再叠加业务约束（如禁止引号、限定域名长度）。
用 net/mail 做最小可信校验
这是最稳妥的第一步，能筛掉 95% 明显非法输入（空字符串、无 @、多个 @、结尾 @ 等）：
import "net/mail"
func isValidEmailBasic(email string) bool {
_, err := mail.ParseAddress(email)
return err == nil
}
注意：mail.ParseAddress 会尝试解析成完整地址（含姓名），对纯邮箱如 user@example.com 也能正确处理；但它不校验域名是否存在或 MX 记录，只是语法层面合规。
- 它接受
user+tag@example.com（带加号的别名） - 拒绝
@example.com、user@、user@@example.com - 不拒绝
"test"@example.com—— 这是 RFC 合法但多数系统不支持的写法
用正则补业务层限制（推荐模式）
如果必须用正则（例如前端快速反馈、日志过滤），别追求 RFC 全覆盖，聚焦常见合法格式 + 排除明显风险：
立即学习“go语言免费学习笔记（深入）”；
var emailRegex = regexp.MustCompile(`^[a-zA-Z0-9._+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`)
func isValidEmailStrict(email string) bool {
if !emailRegex.MatchString(email) {
return false
}
// 再过一遍 net/mail，双重保险
_, err := mail.ParseAddress(email)
return err == nil
}
这个正则刻意排除了以下内容：
- 开头或结尾的点：
.user@example.com、user.@example.com - 连续点：
user..name@example.com - 短域名：
user@a.co（要求 TLD 至少 2 字符） - IP 形式域名：
user@192.168.1.1（没包含在正则里）
如果你的业务允许国际化域名（IDN），需额外用 golang.org/x/net/idna 转换后再校验，否则中文域名会直接被正则拒绝。
容易踩的坑：大小写、空白符和 Unicode
邮箱本地部分（@ 前）理论上区分大小写，但几乎所有服务商都转为小写处理；域名部分必须小写。别在正则里写 [A-Z] 以为能捕获大写用户名——实际应统一转小写再校验：
email = strings.TrimSpace(email)
if email == "" {
return false
}
email = strings.ToLower(email) // 统一小写再进正则或 ParseAddress
另外，用户可能粘贴带不可见字符的邮箱（如零宽空格、BOM），strings.TrimSpace 不够，建议用 strings.Map 清理控制字符：
cleanEmail := strings.Map(func(r rune) rune {
if unicode.IsControl(r) || unicode.IsSpace(r) {
return -1
}
return r
}, email)
真正麻烦的是 emoji 邮箱（如 ??@example.com）——Go 的 net/mail 目前不支持，正则也很难安全匹配。除非明确需求，否则直接拒绝。
