用strings.Split提取域名最直接，但必须用strings.Index找第一个@再截取，避免多@脏数据导致panic；net/mail.ParseAddress更健壮但开销大，适合需兼容RFC格式的场景。
用 strings.Split 提取域名最直接，但要注意 @ 符号位置
Go 没有内置的邮箱解析函数，strings.Split 是最快捷的起点。关键不是拆一次，而是确保只按第一个 @ 拆——因为邮箱本地部分（如 user+tag 或 first.last）里可能含点或加号，但不会含 @；而域名部分才真正需要。
常见错误是写成 strings.Split(email, "@")[1]，这在邮箱含多个 @（非法但可能出现在脏数据中）时 panic 或返回错值。
- 正确做法：用
strings.Index找第一个@，再用email[index+1:]截取 - 更稳妥：用
strings.LastIndex—— 实际上邮箱最多一个@，所以Index和LastIndex效果一样，但语义更准 - 必须先校验
index != -1，否则越界 panic
用 net/mail 解析更健壮，但开销略大
如果输入来自用户表单、日志或不可信源，net/mail.ParseAddress 或 net/mail.Address 能处理带引号、空格、中文昵称的格式（如 "张三" <zhang></zhang>），但它不直接返回域名，得再从 Address.Address 字段二次提取。
注意：ParseAddress 会尝试解析整个地址字段，对纯邮箱字符串（如 test@domain.co.uk）没问题；但若输入是 test@domain@invalid，它会返回 error，而不是静默截断。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 适合场景：需兼容 RFC 5322 格式、或后续还要提取姓名、处理编码
- 不适合场景：高吞吐日志清洗、已知格式干净的内部系统
-
ParseAddress不验证域名合法性，只做语法解析；strings.Split同样不校验，二者都不替代 DNS 或 MX 检查
处理国际化域名（IDN）要额外转码
如果邮箱域名含中文、日文等（如 user@例子.测试），Go 的 net/url 或 golang.org/x/net/idna 可转成 ASCII 兼容编码（ACE），即 user@xn--fsq.xn--0zwm56d。原始字符串拆出来的仍是 Unicode，但下游系统（如 SMTP、数据库索引）常要求 ACE 格式。
- 仅当明确需要与 DNS 交互或存储标准化域名时才用 IDN 转换
- 直接用
strings.Split得到的是原始 Unicode 域名，显示友好但可能被某些服务拒绝 - 转换示例：
idna.ToASCII("例子.测试")→xn--fsq.xn--0zwm56d，失败时返回 error，需检查
正则表达式容易过度设计，且性能差
写 regexp.MustCompile(`@([^@]+)$`) 看似通用，但实际没必要。相比 strings.Index，它多出编译开销、匹配回溯风险，且无法比原生字符串操作更准确——毕竟邮箱域名规则（如不能以连字符开头/结尾、长度限制）本就该由专门库（如 mailsherpa）或业务层校验，不该靠正则兜底。
- 唯一适用正则的场景：批量混杂文本中“捞出邮箱”，此时需先匹配完整邮箱，再提取域名
- 单独提取已知合法邮箱的域名，正则纯属增加维护成本和 CPU 时间
- 别用
.*@(.*)—— 它会贪婪匹配到最后一行末尾，结果完全不可控
