setcustomvalidity() 仅存储错误文案，需配合 reportvalidity() 触发提示；合法时必须设为''；ios safari 中 blur 失效，应改用 change/focusout 或表单 submit 统一校验。
为什么 setCustomValidity() 设了但没反应
因为 setCustomValidity() 只是“存个错误文案”，不校验、不弹窗、不改样式。浏览器不会主动读取它并显示——除非你手动触发验证或用户提交表单。
常见错误现象：只写 emailInput.setCustomValidity('邮箱格式不对')，页面毫无反馈；或者输对了却还卡着红框、提示不消失。
- 必须配合
reportValidity()才能立刻弹出自定义气泡（比如在blur时） - 合法时必须设为
''（空字符串），null或undefined都无效，否则字段永远处于“自定义无效”状态 - 如果监听的是
input事件，每打一个字都调reportValidity()，体验极差；应改用blur或submit
移动端 iOS Safari 的 blur 不触发问题
iOS Safari 点击键盘「完成」按钮后，blur 事件不触发，导致自定义提示卡在上一次错误状态，用户无法继续操作。
解决思路不是等 blur，而是补充监听 change + focusout，并在表单级兜底处理：
-
change在输入值变更且失焦后触发，比blur更可靠（尤其软键盘收起场景） -
focusout是冒泡版blur，部分 iOS 版本对其支持更稳定 - 提交时统一用
form.checkValidity()拦截，避免依赖单个事件
示例逻辑：emailInput.addEventListener('change', handleEmailValidation)，再加一层 form.addEventListener('submit', preventDefaultAndValidate)。
如何让自定义提示不和原生气泡打架
原生 invalid 事件会在浏览器判定失败时立即触发，但它和 setCustomValidity() 并不互斥——两者可共存，但顺序和时机容易冲突。
关键点在于拦截时机：必须在原生气泡弹出前阻止它，否则会闪一下默认提示再覆盖，体验割裂。
- 监听
invalid事件，并在回调中调e.preventDefault() - 此时再调
e.target.setCustomValidity('...')+e.target.reportValidity()，就能稳稳接管 - 注意：
invalid不冒泡，也不能取消已弹出的提示，所以一定要在首次验证失败时就监听好
别忘了：只要 setCustomValidity() 被设过非空值，后续所有验证都会优先用它，哪怕正则变了、值对了，也得手动清空。
为什么 placeholder 不能替代格式提示
placeholder="请输入邮箱" 这类模糊提示，在移动端 Safari 上不仅起不到引导作用，还可能因渲染兼容问题被截断或错位；更重要的是，它完全不参与验证逻辑。
真正有效的做法是结合语义化与即时反馈：
- 用
type="email"唤起邮箱键盘、触发基础校验（含 @ 和 .） -
placeholder改为具体样例，如placeholder="name@example.com"，iOS 渲染更稳 - 校验逻辑里区分空值和格式错，分别给不同文案：
value.trim() === ''→ “邮箱不能为空”；!emailRegex.test(value)→ “邮箱格式不对”
最易被忽略的一点：required 在 JS 主动监听 input 时不自动生效，必须手动调 checkValidity() 或靠 reportValidity() 触发——否则空值根本不会进你的校验分支。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
