为何<input type="email">会误判邮箱地址的有效性？

验证偏差的具体表现 #

1. 维基百科认定合法，但被<input type="email">判定无效的邮箱： #

" "@example.org
"john..doe"@example.org
"very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com
postmaster@[123.123.123.123]
postmaster@[IPv6:2001:0db8:85a3:0000:0000:8a2e:0370:7334]

2. 维基百科认定无效，但被<input type="email">判定有效的邮箱： #

1234567890123456789012345678901234567890123456789012345678901234+x@example.com

导致偏差的核心决策原因 #

• 实用优先，放弃边缘场景
  HTML标准制定时，核心目标是覆盖绝大多数日常使用的邮箱格式，而非完全遵循RFC规范的所有细节。你列出的那些带引号、含特殊字符或用IP作为域名的邮箱，现实中几乎没有用户使用，支持这些格式会大幅增加验证逻辑的复杂度，反而可能干扰普通用户的正常输入校验。

• 简化复杂规范，平衡实现成本
  邮箱的RFC规范（如RFC 5322）内容极其复杂，包含大量边缘规则，完全实现对应的正则会异常冗长，既影响浏览器端的验证性能，也不利于开发者理解和调试。HTML标准选择了一个简化的规则子集，在验证准确性和实现成本之间做了妥协。

• 长度限制的妥协处理
  RFC 5321明确规定邮箱本地部分（@前的内容）最长为64字符，但HTML验证规则没有严格执行这一限制。原因在于部分邮件系统早已放宽了该限制，且浏览器端优先级更高的是格式校验而非长度校验，加上超长本地部分的使用场景极少，因此没有强制纳入验证规则。

• 兼容性优先的历史选择
  早期不同浏览器的邮箱验证实现差异较大，HTML标准在统一规则时，选择了大多数浏览器都能轻松适配的方案，避免因过于严格的规则引发兼容性问题。比如IP形式的邮箱域名，很多邮件服务器本身就不支持，因此HTML标准直接将其排除在验证范围之外。

内容的提问来源于stack exchange，提问作者303