邮箱地址格式的上下限：标准允许不等于服务商接受

写注册表单时，最容易踩坑的一件事是：把「标准允许」当成「服务商接受」。邮箱地址格式的标准本身相当宽松，而真实服务商出于各种原因又窄得多；如果表单只按自己想象的规则来校验，就会出现用户明明有一个能用的地址，却怎么也提交不上去的情况。

一个地址被「@」分成两半

一个邮箱地址由「@」分成局部部分与域名部分：前面是收件人的标识，后面是收信服务的所在域。发送方拿到地址后，先看「@」后面的域名，找到该域名对外公布的收信服务器记录，再把信投递过去。

这两半的规则并不一样。域名部分要能被解析，所以它的写法受域名体系约束；局部部分由该域的运营方自行规定，标准只画了外框。理解这个分工，后面很多「为什么它能用、它不能用」的问题就自动有了答案。

需要留意的是，如果域名部分解析不到收信服务器，或者对方直接拒绝，这封信就不会被送达。地址写得再漂亮也改变不了这一点——投递的成功与否取决于域名的收信配置，而不是字符串本身有多规整。

标准对地址长度画了三条线：局部部分最长 64 字节，域名最长 255 字节，整个地址最长 256 字节（这个长度是含尖括号在内的）。注意单位是字节而不是字符，这是很多实现出错的地方。

最后一行的「收得更紧」不是标准要求，而是工程上的习惯：很多服务在存储与传输上留了余量，于是实际接受的地址比标准短。也就是说，一个地址在标准意义上合法，仍然可能被某家服务拒绝。

因为标准定义的是「什么叫合法」，不是「什么叫好用」。下面这些写法标准都允许，但真到了注册表单或收信服务那里，接受度差别很大。

上面每一条都属于「标准允许，服务商不一定接受」。如果你的产品面向普通用户，正确的期待是：这些写法极少出现，遇到时给出清楚的提示，而不是把它们当成攻击输入。

严格正则有三个具体害处。第一是会误杀：写得太紧，就会把合法的地址拒之门外，而用户没有任何办法绕过去。第二是会把判断放错位置：真正决定能不能收到信的，是域名的收信配置，而不是字符串形状。第三是维护成本：地址的可接受范围会随标准与政策变化，你写死的那条规则迟早变得不对。

更稳的替代做法是「宽进严出」：表单只做最基本的检查，比如有没有「@」、两半是否都非空、有没有明显的空格，然后靠「发一封确认信」来确认地址真实可用。这也是行业里最常见的做法，因为它把判断交给了唯一可靠的手段——能不能收到信。

想亲眼看看不同的地址写法会有什么结果，可以打开临时邮箱生成一个地址，再对比标准里那些少见写法。工具本身走的是常见服务商的宽松口径：地址由系统生成、前缀可以自定义，收件箱只收投给这个地址的信。

在测试里，它的用处是提供一批形状可控的地址：想测「超长局部部分」，就让前缀长一点；想测大小写，就把前缀换一种写法。地址从哪来、信怎么到收件箱，见临时邮箱原理。

存储字段要按标准留足空间，并明确单位是字节。局部部分按 64 字节、域名按 255 字节准备，完整地址再留余量；如果数据库字段按字符数算，遇到多字节字符就会溢出。这是最容易在上线后才发现的一类问题。

大小写方面，域名部分不区分大小写，局部部分理论上可以区分，但现实中的服务商基本都当作不区分处理。因此不建议依赖大小写来区分用户，也不要因为用户把小写写成大写就判定为非法地址。用户从别处复制地址时，前后带上空格非常常见，提交前统一去掉首尾空格，能避免大量无意义的报错。

校验规则要能修改，最好做成一处配置而不是散落在多处。非 ASCII 地址的处理方式与地址的国际化格式可以对照国际地址格式；验证流程本身该怎么覆盖，见邮箱验证测试。

校验规则要测到边界，就得能造出刚好在边界上的样本。最直接的办法是控制前缀长度：把局部部分造到接近上限，再加一个字节，看表单在哪一边开始拒绝。长度按字节算，所以用多字节字符时，同样的字符个数会占用更多空间——这一点在只数「多少个字」的测试里很容易被漏掉。

大小写与空格也要各造一个样本：全大写的前缀、前后带空格、中间混入空格、末尾多一个点。重点不是让它们全部通过，而是确认系统的行为是明确的：要么干净地接受并规范化，要么给出能理解的提示，而不是抛出无法解释的错误。

还有一类样本值得常备：域名部分写错一位、缺少「@」、有两个「@」。这些不是合法地址，但只要系统在客户端与服务端给出同样的结论，就不会出现「前端放行、后端报错」这种让人困惑的组合。

样本最好是固定的几条，随测试用例一起维护。临场手写地址容易造出与真实情况无关的形状，测了半天也说明不了问题。

把你现在的表单规则拿出来对一遍：有没有把标准允许的写法判成非法，有没有把长度按字符数当成字节数。需要一批可用的测试地址时，打开临时邮箱直接生成。

文中的地址与写法只用于测试表单校验，不能当作真实身份或联系方式。