邮箱地址是Android应用里最常见的输入项之一，注册、登录、找回密码、邀请好友都离不开它。但很多团队对邮箱的测试只停留在“能通过控件非空判断”或“简单正则匹配”，上线后往往收到用户反馈：输入了带加号的Gmail地址被拦截，或者形如 user@localhost 的内部邮箱无法通过。出现这些问题的根源在于邮箱地址的合法性判断分为不同层级：字符格式、域名结构、邮件系统可达性。这篇文章从Android自带API出发，逐步拆解格式校验、真实性探测和自动化测试的完整思路。
一、Android自带的Patterns.EMAIL_ADDRESS到底做了什么
Android SDK中的 android.util.Patterns.EMAIL_ADDRESS 是一个预编译的正则表达式，开发时可以直接拿来判断字符串是否像邮箱地址。使用方式也很简单，核心代码只有一行：
import android.util.Patterns;
public boolean checkEmail(String email) {
return email != null && Patterns.EMAIL_ADDRESS.matcher(email).matches();
}
这个工具类在大多数常规场景下已经够用，但它的匹配规则只覆盖了字符层面的格式要求。它并不会检查域名是否真实存在，也不会验证域名下有没有邮件服务器。更重要的是，它对部分符合RFC标准的地址会误判。例如某些Android版本中的正则要求顶级域名长度必须在2到6个字符之间，这就导致一些较新的顶级域名如 .technology、.international 被直接过滤掉。另外，虽然Gmail等主流服务支持本地部分带加号扩展，如 user+tag@gmail.com，但某些旧版本Patterns仍可能因为特殊字符范围或点号位置而返回不一致的结果。
还有一个容易被忽略的问题：Patterns.EMAIL_ADDRESS只做输入过滤，并不负责处理Unicode字符、国际化域名或IP形式的域名。比如形如 user@[192.168.1.1] 的地址在部分内部系统中合法，但用它来测试基本都会失败。所以建议把这个API当作第一层粗糙过滤，不要让它承担“邮箱一定有效”的责任。
二、用正则和结构拆分补齐格式测试
如果仅靠系统自带正则不够用，可以自行设计一个更贴近RFC 5321和SMTP实际限制的校验方案。邮箱地址被“@”分成两部分：本地部分和域名部分。本地部分最大64个字符，整个地址最大254个字符，域名部分最大255个字符。本地部分可以包含点号、百分号、加号、下划线等常见符号，但点号不能出现在开头、结尾，也不能连续出现两个点。域名部分由多个标签组成，每个标签不能以连字符开头或结尾。
下面这段Kotlin代码把这些约束拆开处理，比单条正则更容易维护，也方便针对个别规则调整：
fun isValidEmailFormat(email: String): Boolean {
if (email.isBlank() || email.length > 254) return false
val parts = email.split('@')
if (parts.size != 2) return false
val local = parts[0]
val domain = parts[1]
if (local.isEmpty() || local.length > 64) return false
if (domain.isEmpty() || domain.length > 255) return false
if (local.startsWith('.') || local.endsWith('.') || local.contains("..")) return false
val localRegex = Regex("^[A-Za-z0-9.!#$%&'*+/=?^_`{|}~-]+$")
if (!localRegex.matches(local)) return false
val domainLabels = domain.split('.')
if (domainLabels.any { it.isEmpty() || it.startsWith('-') || it.endsWith('-') }) return false
val domainRegex = Regex("^[A-Za-z0-9.-]+$")
if (!domainRegex.matches(domain)) return false
return domainLabels.last().length >= 2
}
这个函数处理了常见的误判场景，包括连续点号、点号在首尾、域名标签以连字符开头或结尾等。同时也支持不带点的域名，例如 user@localhost 在当前逻辑下是可以通过的，因为域名只有一个标签，顶级域名长度至少为2即可。但如果业务中只允许公网邮箱，可以改成要求域名至少包含一个点。
实际测试时可以把下面这些地址作为基本样本：
test@ipipp.com应当通过first.last+tag@sub.domain.co应当通过user@localhost视业务规则决定是否通过user@应当拒绝@ipipp.com应当拒绝user..name@ipipp.com应当拒绝user@-ipipp.com应当拒绝user@example.c应当拒绝
如果还要支持IP形式的域名，可以在这个函数之外单独加一个分支，用正则匹配 [数字.数字.数字.数字] 的结构，并把方括号去掉后再解析。这样既不影响常见邮箱格式，也能兼容内部系统的需求。
三、真实性测试：DNS MX记录与确认邮件
格式校验通过只说明这个字符串结构上像邮箱，不代表它真的能收到邮件。比如 test@ipipp.com 格式完全正确，但 ipipp.com 可能根本没有配置邮件服务器。真实性验证通常依赖两类手段：DNS MX记录查询和SMTP会话探测。Android端直接查询MX记录并不方便，因为标准Java库没有提供专门查MX的API，需要引入dnsjava这样的第三方库，或者把查询逻辑放到后端服务。
在移动端比较合理的做法是，前端只把用户输入的邮箱地址发给自己的服务器，由服务器完成格式检查、MX查询以及可选的SMTP探测，最后把结论返回给客户端。下面是一个基于Retrofit的接口定义示例，展示客户端如何与后端协作：
interface EmailVerifyService {
@GET("api/email/verify")
suspend fun verifyEmail(@Query("email") email: String): EmailVerifyResult
}
data class EmailVerifyResult(
val formatValid: Boolean,
val mxValid: Boolean,
val smtpCheck: Boolean,
val score: Int
)
至于SMTP探测，做法通常是连接目标域名的MX服务器，依次尝试 EHLO、MAIL FROM、RCPT TO 等命令，观察服务器是否接受该收件人。但这套方法有两个明显问题：一是很多邮件服务器出于反垃圾邮件目的禁用了VRFY命令，或者对RCPT TO校验返回模糊结果；二是移动端直接发起SMTP连接会消耗流量和电量，还可能被服务器拉黑。因此生产环境更推荐发送一封带验证链接的确认邮件，让用户点击链接来完成真实性验证。这样既验证了邮箱确实能收信，也顺便确认了该邮箱归当前用户所有。
本地开发或测试环境可以借助GreenMail、MailHog等工具搭建一个模拟SMTP服务器，把邮件投递到内存队列中，再用测试代码读取验证邮件内容。这样既能验证邮件发送逻辑，又不会误发真实邮件。测试完成后，把后端邮箱校验服务接入CI流程，可以持续监控MX查询服务的稳定性。
四、用JUnit把邮箱测试场景固化下来
校验逻辑不是写完就一劳永逸，后续修改正则或调整长度限制时很容易引入回归。把邮箱校验逻辑放在纯JVM模块中，就可以用JUnit写本地单元测试，不需要启动模拟器，执行速度也很快。下面是一个简单的测试类结构：
import org.junit.Test;
import static org.junit.Assert.*;
public class EmailValidatorTest {
@Test
public void validAddresses() {
assertTrue(EmailValidator.isValid("user@ipipp.com"));
assertTrue(EmailValidator.isValid("first.last+tag@sub.domain.co"));
assertTrue(EmailValidator.isValid("user@localhost"));
}
@Test
public void invalidAddresses() {
assertFalse(EmailValidator.isValid("user@"));
assertFalse(EmailValidator.isValid("@ipipp.com"));
assertFalse(EmailValidator.isValid("user..name@ipipp.com"));
assertFalse(EmailValidator.isValid("user@-ipipp.com"));
assertFalse(EmailValidator.isValid("user@example.c"));
}
}
测试用例不应该只覆盖“应该通过的地址”，更要把各种异常输入都固定下来。建议至少包含这些边界场景：空字符串、前后有空格、总长度超过254、本地部分超过64、点号连续、点号在首尾、域名标签以连字符开头或结尾、缺少@、多个@、仅包含数字的域名、包含Unicode字符的地址、带IP形式的域名。每一条测试都代表一个历史线上问题或一次规则变更，这样再改代码时可以直接看到影响面。
自动化测试的意义还在于倒逼校验逻辑的模块化。如果邮箱校验代码和Activity、ViewModel高度耦合，就难以单独写测试。把邮箱验证器抽成一个独立类，不依赖Android Context，才能在JVM上快速执行。这也是很多Android项目逐渐把纯逻辑代码下沉到Kotlin Multiplatform或独立Java模块的原因之一。
综合来看，Android邮箱地址测试不应只停留在输入框层面。利用 Patterns.EMAIL_ADDRESS 做前置过滤，再用结构拆分和正则补强格式约束，接着通过后端DNS和确认邮件验证真实性，最后用JUnit用例把所有规则固化下来，这样形成的完整测试体系可以明显降低脏数据进入业务系统的概率。
Android邮箱验证邮箱地址正则Email地址校验修改时间：2026-09-22 02:42:20