Go中邮箱验证需分两步：先语法校验再SMTP确认，推荐宽松正则^[a-zA-Z0-9.\_%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$；手机号须按国家区号定制规则，预编译正则并避免回溯爆炸。
Go 里用 regexp.MatchString 验证邮箱，别直接抄网上正则
网上一堆 ^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$ 看似简洁，实际会漏掉合法邮箱（如 test+tag@example.co.uk），或误判带 Unicode 的现代邮箱（如 用户@域名.中国）。Go 标准库不支持 IDN（国际化域名）自动转 Punycode，所以严格验证必须分两步：先做语法校验，再交由 SMTP 层或第三方服务确认可达性。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 对内部系统或表单前端校验，用宽松但安全的正则：
^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$（禁用 Unicode，避免regexp引擎兼容问题） - 若需支持中文域名，先用
golang.org/x/net/idna转成 ASCII：toASCII, err := idna.ToASCII("用户@例子.中国")，再喂给正则 - 永远不要只靠正则判断邮箱是否“存在”——
regexp.MatchString返回true只代表格式像，不代表能收信
手机号验证得按国家区号切，别用一个正则打天下
中国大陆手机号（1[3-9]\d{9}）和印尼（^62[8-9]\d{10}$）、美国（^\+1[2-9]\d{2}[2-9]\d{2}\d{4}$）规则完全不同。硬写一个“通用”正则，要么漏号段，要么误杀携号转网号码（如中国 170/171 段）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 明确业务覆盖区域，只实现对应国家规则。例如只服务国内用户，就用：
^1[3-9]\d{9}$（注意：去掉^和$容易被绕过，比如输入abc13812345678def也会匹配成功） - 用户输入含国际前缀（如
+86 138****5678），先用strings.TrimSpace清空空格，再用strings.TrimPrefix剥离+和国家码，最后校验剩余数字长度和号段 - 正则编译一次复用，别在循环里反复调
regexp.Compile：var phoneReg = regexp.MustCompile(`^1[3-9]\d{9}$`)
regexp.Compile 失败时 panic 是常态，不是 bug
写错正则（比如少个 ] 或多嵌套括号），regexp.Compile 会直接 panic，而不是返回 error。线上服务一旦遇到非法输入触发 panic，整个 goroutine 就崩了。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有正则字面量在 init 函数或包级变量中预编译：
var emailReg = regexp.MustCompile(`^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$`)，这样启动时就暴露问题，而非运行时 - 如果正则来自配置或用户输入（极不推荐），必须用
regexp.Compile并显式处理 error：re, err := regexp.Compile(userInput); if err != nil { return false } - 别信 “这个正则很简单，不可能错”——
\d在 Go 正则里默认不匹配 Unicode 数字，而[0-9]才是安全选择
性能差的根源常在正则本身，不在 MatchString
有人测出 MatchString 比字符串 strings.Contains 慢十倍，就以为“正则慢”，其实往往是正则写法导致回溯爆炸。比如验证邮箱时用 .*@.*\..*，输入超长字符串（如 1MB 日志片段）会让引擎卡死。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 避免贪婪匹配 + 多重嵌套，改用原子组或非捕获组。例如邮箱本地部分不用
[^@]*，而用[a-z0-9._%+-]+明确字符集 - 手机号验证优先用
len(s) == 11 && s[0] == '1'快速筛掉明显不符的，再进正则——短路比正则快得多 - 用
go tool trace实际压测，别靠直觉。常见瓶颈是反复Compile，不是MatchString本身
真正麻烦的从来不是“怎么写正则”，而是“怎么定义‘合法’”——邮箱要不要支持 name@sub.domain.co.jp 这种多级域名？手机号要不要接受带括号和横线的格式（(138) 1234-5678）？这些业务规则必须前置明确，否则正则越改越乱。
