原生校验是必须优先启用的防线，不写JS即可拦截80%低级错误，且影响无障碍、SEO和移动端键盘；required与type逻辑分离，空值时type不校验，须配合pattern强化约束。
原生校验不是“能用就行”，而是必须优先启用的防线——它不写 JS 就能拦截 80% 的低级输入错误，且对无障碍、SEO、移动端键盘触发都起决定性作用。
required 和 type 属性为什么不能混着乱用
很多人以为 required 加上 type="email" 就万事大吉，但实际中常出现“空邮箱也能通过校验”的情况。这是因为浏览器只在字段有值时才触发 type 校验，而 required 只管是否为空——两者逻辑是分离的，不是叠加增强。
-
type="email"对""（空字符串）或" "（纯空格）不报错，它只在校验非空值时才走邮箱格式规则 - 如果用户输入了
"@example.com"或"user@"，部分老版本 Chrome 会放过，而 Safari 可能直接标红 - 真正保险的做法是：必填字段必须同时带
required，且用pattern补充强约束，比如pattern="^[^s@]+@[^s@]+.[^s@]+$" - 移动端尤其要注意：
type="email"能唤起邮箱键盘，但pattern不影响键盘类型，所以别为了正则放弃type
pattern 正则写错的三个典型表现
写 pattern 最容易自以为对了，结果一测就漏——浏览器不会报语法错误，只默默失效。
- 忘记加首尾锚点：
pattern="[0-9]{11}"会匹配"abc12345678901def"，正确写法是pattern="^[0-9]{11}$" - 未转义特殊字符：比如想匹配字面量点号
.，写成pattern=".*.com"是错的，.在正则里是通配符，必须写成pattern=".*\.com" -
title属性没同步更新：当pattern失败时，浏览器只显示title值；如果留着默认 “Please match the requested format”，用户根本不知道要填什么
setCustomValidity 被调用后不恢复的坑
用 JavaScript 调 setCustomValidity() 很方便，但一旦设了非空字符串，该字段就永远 invalid，除非你手动清空——哪怕用户后来输对了，表单依然提交不了。
立即学习“前端免费学习笔记（深入）”；
- 常见错误：只在验证失败时调
input.setCustomValidity("xxx")，却忘了成功时调input.setCustomValidity("") - 更稳妥的做法是把校验逻辑封装成函数，在
input和blur事件里都执行，统一处理成功/失败分支 - 注意：调用
setCustomValidity("")后，需再调一次input.reportValidity()才能刷新 UI 状态（尤其在动态修正后） - 不要在
submit事件里集中调setCustomValidity：这时浏览器已内置校验过一遍，重复设置可能干扰原生提示气泡位置
为什么 maxlength 在 textarea 里有时失效
maxlength 对 <input> 稳定有效，但在 <textarea></textarea> 上容易被绕过，尤其涉及中文、emoji、换行符时。
- 根本原因：不同浏览器对“字符”的定义不一致。Chrome 把一个 emoji 算作 2 个码点（如 ??），而 Firefox 可能算作 1 个“字符”
- 换行符
maxlength计的是 Unicode 字符数，不是字节数，导致实际长度和预期偏差 - 解决方案：如果业务真要卡死长度（比如评论限 200 字），别只靠
maxlength，得用 JS 监听input事件，用str.codePointCount或正则/[uD800-uDBFF][uDC00-uDFFF]/g统计真实可视字符数，并主动截断
最易被忽略的一点：所有原生校验属性（required、pattern、minlength 等）在表单提交时才批量触发，但用户感知不到这个时机——他们需要的是输入过程中就明确知道哪里错了。所以，blur + setCustomValidity + 实时计数，才是生产环境真正落地的最小闭环。
