HTML5中type="email"的邮箱校验无法完全禁用，但可通过改用type="text"+pattern、form加novalidate后JS手动验证，或使用inputmode="email"三种方式绕过原生强校验。
HTML5 表单中 type="email" 的邮箱格式校验不能完全“禁用”，但可以绕过或弱化——关键在于理解浏览器原生验证的触发条件和替代方案。
为什么 input[type="email"] 一定会校验邮箱格式？
这是 HTML5 规范强制要求的行为：只要元素是 type="email"，且没有 novalidate 属性，表单提交时浏览器就会执行基础邮箱格式检查（如必须含 @、不能以 @ 开头等）。这不是 JS 控制的，无法用 setCustomValidity('') 或 reportValidity() 覆盖掉这个底层规则。
常见错误现象：
- 用户输入 user@domain（缺后缀）被拒绝，但业务上允许内网邮箱；
- 输入 admin@localhost 或 test@example 被标红，实际后端能接受。
去掉强校验的三种可行做法
不是“禁用”，而是换一种更可控的方式表达语义和行为：
- 改用
type="text"+ 自定义pattern属性：例如，只校验你真正关心的结构，不依赖浏览器内置邮箱逻辑 - 保留
type="email"，但添加novalidate到整个，再用 JS 手动调用checkValidity()或自行验证——这样浏览器跳过原生校验，你完全掌控逻辑 - 用
inputmode="email"替代type="email"：在移动端唤起邮箱键盘，同时彻底避开格式校验（inputmode是纯提示属性，无验证语义）
required 和 pattern 组合时要注意什么？
如果用了 type="text" + pattern，required 仍生效，但空值不会触发 pattern 校验。也就是说：
- 空输入 → 只报 “请填写此字段”（required 错误）
- 非空但不匹配 pattern → 报自定义 title 提示
- 想让空值也走 pattern 校验？得用 JS 监听 input 或 blur，手动调用 setCustomValidity()
性能影响很小，但兼容性需注意：inputmode 在 Safari 16.4+ 才稳定支持，老版本 iOS 会回退为 text 键盘。
立即学习“前端免费学习笔记（深入）”；
最易被忽略的一点：即使你用 JS 移除了所有验证逻辑，Chrome DevTools 的 Elements 面板里仍可能显示 “Valid email address required” 提示——这只是渲染层残留，不影响实际行为，别被它误导。
