必须在oninvalid事件处理器第一行调用e.preventdefault()才能阻止原生气泡，且需配合novalidate、oninput清空校验及手动validity状态判断，否则safari等浏览器仍会弹出不可控浮层。
oninvalid事件里必须调用e.preventDefault()
浏览器在判定字段无效时，会同步触发invalid事件，并紧接着弹出原生气泡——这个气泡无法用CSS控制，也不能延迟或改样式。唯一能拦住它的时机，就是invalid事件处理器内立刻执行e.preventDefault()。
常见错误是只设setCustomValidity()却不阻止默认行为，结果自定义文案没显示，原生气泡照常弹；或者写了e.preventDefault()但放在异步回调里（比如setTimeout），已经错过拦截窗口。
-
invalid事件只在浏览器内部校验失败后触发一次，不会因你反复调用setCustomValidity()而重复触发 - 必须在事件监听函数第一行就调用
e.preventDefault()，否则无效 - 如果表单用了
novalidate，invalid事件根本不会触发——它依赖原生校验机制，禁用后就没了
清空setCustomValidity()才能让invalid事件持续生效
很多开发者在input事件里调用setCustomValidity('')，以为清空了状态，结果invalid事件再不触发。这是因为setCustomValidity('')会让元素的validity.valid变为true，后续输入错误时，浏览器可能跳过校验直接认为“已修复”，不再发invalid事件。
正确做法是：只在用户输入合法时清空，且确保校验逻辑和setCustomValidity()调用严格匹配。
- 错误写法：
input.addEventListener('input', () => el.setCustomValidity(''))→ 一输就清，invalid事件只触发一次 - 正确写法：在
input事件里做正则判断，仅当值合法才setCustomValidity('')；非法时设具体文案 - Safari尤其敏感，
oninput里漏掉setCustomValidity('')可能导致blur时强制弹层
自定义UI要配合validity状态手动渲染
invalid事件本身不提供错误类型细节，只表示“当前值被浏览器判为无效”。要精准显示提示，得读取el.validity对象里的布尔属性，比如valueMissing、typeMismatch、patternMismatch。
别直接用el.validationMessage——它返回的是浏览器默认文案（如“请填写此字段”），不是你设的setCustomValidity()内容；而且Safari下这个值可能为空或不可靠。
- 推荐结构：
if (el.validity.valueMissing) { renderError('手机号不能为空'); } - 避免把所有错误塞进同一个提示文案，用户需要知道错在哪，而不是只看到“不合法”
- 自定义UI需额外管理显隐状态，比如添加
error-message元素并切换visible类，不能只靠CSS:invalid伪类
Safari下oninvalid单独用基本无效
macOS Safari（16+）对invalid事件的处理更激进：即使你绑了invalid监听并preventDefault()，它仍可能在blur时弹阻断式浮层——这个浮层会卡住JS执行，连console.log都来不及输出。
必须三者齐上：novalidate关提交校验 + oninvalid="this.setCustomValidity('')"清空消息 + oninput="this.setCustomValidity('')"防失焦激活。缺一不可。
- 只加
novalidate：submit时不弹，但blur仍弹 - 只绑
invalid事件：Safari无视preventDefault()，照样弹 - 真正可靠的做法是放弃原生校验，用
form.checkValidity()+ 手动遍历校验，在submit时统一渲染
invalid事件不是万能钩子，它受浏览器策略制约极大，尤其在Safari里，过度依赖反而容易翻车。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
