浏览器原生验证仅在表单提交时自动触发，不实时校验；type="email" 仅做基础格式检查（如含@和域名），不验证真实性或RFC全规范；正则手动验证更严格且必要，推荐使用 /^\S+@\S+.\S+$/ 覆盖99%场景；应避免onblur弹alert，改用setCustomValidity配合错误提示元素；iOS Safari需监听input事件并防抖以应对粘贴后change未触发问题。
浏览器原生验证会自动触发吗
会，但仅限表单提交时（比如点击 <button type="submit"> 或回车），不会在用户输入过程中实时校验。只要 input 的 type="email" 且所在表单未设置 novalidate，浏览器就会用内置规则检查格式是否像邮箱（含 @ 和域名部分）。但注意：它不发请求、不查邮箱是否真实存在，也不保证符合 RFC 5322 全部规范——比如 a@b.c 会被认为合法，test@.com 则被拒绝。
正则手动验证比 type="email" 更严格吗
是的，而且常有必要。原生验证太宽松，比如允许 "a b"@example.com（带引号和空格）或 user+tag@example.co.uk（+号和多级域名），而很多后端或业务逻辑并不接受这些。若需统一约束，建议用 JS 配合正则：
const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
这个表达式排除了空格和 @ 前后连续 @ 的情况，比原生更贴近常见业务要求。但别用网上那些“完美匹配 RFC”的超长正则——维护难、性能差、兼容性反而差，实际项目里 /^[^\s@]+@[^\s@]+\.[^\s@]+$/ 覆盖 99% 场景已足够。
如何避免 onblur 时反复弹 alert 干扰用户
直接在 onblur 里调用 alert() 是最差体验。应该：
- 用
setCustomValidity()配合reportValidity()复用浏览器提示样式 - 只在必要时机（如提交前、或用户离开字段超过 1 秒后）校验
- 把错误信息写进紧邻的
<span class="error"></span>，而非弹窗
立即学习“前端免费学习笔记（深入）”；
emailInput.addEventListener('blur', () => {
if (emailInput.value && !emailRegex.test(emailInput.value)) {
emailInput.setCustomValidity('邮箱格式不正确');
} else {
emailInput.setCustomValidity('');
}
});
移动端 iOS Safari 对 email 输入框的特殊行为
iOS 键盘会自动显示 @ 和 .com 快捷键，但有个坑：当用户粘贴邮箱后快速点「完成」，有时 change 事件没触发，导致 JS 拿到的是旧值。解决方案是监听 input 事件而非 change，并加防抖（300ms 内重复输入只算一次）。另外，iOS 15+ 开始支持 pattern 属性，但它的正则必须完全匹配（即隐式加 ^$），而原生 type="email" 不受 pattern 影响——这两个机制互不干扰，别误以为设了 pattern 就能覆盖原生校验。
