推荐分层验证邮箱：先用轻量正则 ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$ 快速过滤，再用 net/mail.ParseAddress 严格解析语法；该正则覆盖常见合法格式（如带+号的Gmail），拒绝明显非法输入（如@example.com），但不支持国际化邮箱（需先Punycode编码），且最终须依赖ParseAddress捕获RFC合规性错误。
Go 用 regexp.MatchString 验证邮箱是否合法，但别信网上抄来的正则
Go 标准库不提供内置邮箱校验函数，net/mail.ParseAddress 虽能解析，但对格式宽松（比如 "a@b" 也能过）；而网上泛滥的「超长正则」看似严谨，实际会误杀合法邮箱（如带 +tag 的 Gmail、含 Unicode 的国际化邮箱），或漏掉明显非法输入（如 "@example.com"）。真正可用的方案是分层验证：先用轻量正则做快速过滤，再交由 mail.ParseAddress 做语法解析。
推荐的正则模式：^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$
这个正则不是万能的，但平衡了实用性与安全性。它覆盖绝大多数常见邮箱，同时拒绝明显错误：
-
^和$锚定首尾，防止字符串中混入邮箱以外内容（如"abc@example.com and more"不会匹配） -
[a-zA-Z0-9._%+-]+允许本地部分含点、下划线、百分号、加号、短横（Gmail 支持name+tag@gmail.com） -
@后要求至少一个点号 + 至少两个字母的顶级域，排除"user@domain"这类无效域名 - 不支持连续点（
..）、开头/结尾点、空段（@.com），这些本就是 RFC 5322 明确禁止的
使用示例：
import "regexp"
<p>var emailRegex = regexp.MustCompile(<code>^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$</code>)
ok := emailRegex.MatchString("test+notify@gmail.com") // true
ok = emailRegex.MatchString("user@domain") // false
为什么不能只靠正则？net/mail.ParseAddress 才是关键补刀
正则无法处理引号包裹的本地部分（如 "john..doe"@example.com）或带注释的格式（user /* comment */ @example.com），而 mail.ParseAddress 会按 RFC 规范解析并归一化。更重要的是：它能捕获语法错误，且返回结构化结果。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 必须传入完整地址字符串（含可选姓名），例如
"John Doe <john@example.com>"或纯邮箱"john@example.com" - 若只需校验邮箱本身，忽略姓名部分，可提取
addr.Address再走一遍正则（避免""空地址） - 注意：它不验证域名是否存在或 MX 记录，仅检查语法合法性
实操建议：
import "net/mail"
<p>func isValidEmail(s string) bool {
if !emailRegex.MatchString(s) {
return false
}
addr, err := mail.ParseAddress(s)
if err != nil {
return false
}
// 确保解析后仍有有效邮箱（排除只有姓名无地址的情况）
return addr.Address != ""
}
生产环境必须绕开的坑
真实系统里，邮箱校验常被当成“前端提交后立刻拦住用户”的环节，但这容易引发问题：
- 过度依赖正则导致拒绝合法邮箱：比如
user@sub.domain.co.uk中的co.uk是有效二级域，但[a-zA-Z]{2,}会误判为顶级域太短（实际应匹配domain.co.uk整体） - 忽略大小写：RFC 规定本地部分区分大小写，但多数服务不区分；域名部分必须小写，
ParseAddress会自动转小写，正则无需额外处理 - 国际化邮箱（IDN）：含中文、日文等 Unicode 字符的邮箱需先 Punycode 编码（如
例子@中国.cn→xn--fsq0883g@xn--fiqs8s.cn），否则正则和ParseAddress都会失败 - 测试时别只用
gmail.com：务必覆盖user@localhost（开发常用）、test@123.45.67.89（IP 形式域名）、admin@mail.example（无 TLD）等边界情况
最稳妥的做法是：前端用轻量正则提示格式错误，后端用 ParseAddress 做最终校验，并把真正严格的验证（如发确认邮件）留到业务流程中——毕竟邮箱格式合法 ≠ 邮箱真实存在。
