setcustomvalidity() 是唯一能介入原生表单验证流程的 api，通过设置 validity.customerror 状态控制验证结果，需配合 input/blur 事件和 reportvalidity() 使用，并同步更新 aria-invalid 与 classlist 以保证状态一致。
如何用 setCustomValidity() 拦截默认验证并控制错误状态
浏览器原生表单验证会自动阻止提交并显示气泡提示，但无法直接拦截或替换这个行为。setCustomValidity() 是唯一能介入验证流程的 API，它不触发也不取消验证，只修改元素的 validity.customError 状态。调用时传空字符串 "" 表示“通过”，非空字符串（哪怕只是空格）都会让 checkValidity() 返回 false，且触发默认 UI。
- 必须在
input或blur事件中调用，不能仅靠submit事件——因为提交前浏览器已执行验证，此时再设无效值不会改变提交阻断逻辑 -
setCustomValidity(" ")和setCustomValidity("输入不能为空")效果一致，但前者更安全：避免中文字符在某些旧版 Safari 中引发渲染异常 - 调用后需手动调用
reportValidity()才能立即触发 UI 提示；否则要等到用户再次交互或提交时才显示
为什么 reportValidity() 有时不弹提示，或提示位置错乱
根本原因是该方法只对当前元素生效，且依赖其是否在 DOM 中、是否可聚焦、是否有关联的 label。当表单含多个字段、部分被 display: none 或 visibility: hidden 隐藏时，reportValidity() 可能静默失败或聚焦到错误位置。
- 隐藏字段请改用
aria-hidden="true"+tabindex="-1"，而非 CSS 隐藏，否则reportValidity()无法正确计算焦点流 - 动态渲染的字段（如 Vue/React 中新增的 input）必须确保已挂载到 DOM 且完成 layout —— 可在
nextTick或requestAnimationFrame后再调用 - 若使用自定义弹窗替代原生气泡，请在调用
reportValidity()前先event.preventDefault()，否则两者会同时出现
保持验证反馈与 UI 交互一致的关键点
原生验证状态（:valid/:invalid）和 JavaScript 控制的状态（classList、aria-invalid）容易脱节。比如用户手动清空字段后未触发 input 事件，validity.valid 已为 false，但样式没更新。
- 不要只监听
input，必须同时监听change和blur：前者捕获实时输入，后者覆盖粘贴、拖入、自动填充等场景 - 每次验证逻辑结束，同步设置：
el.setAttribute("aria-invalid", !el.checkValidity())和el.classList.toggle("error", !el.checkValidity()) - 禁用原生气泡后（
oninvalid="event.preventDefault()"），务必自行维护aria-live="polite"区域，否则屏幕阅读器无法感知错误
checkValidity() 返回 true 却仍被阻止提交？
这是最常被忽略的细节：表单级验证不仅检查每个字段，还会检查 fieldset[disabled]、input[disabled]、以及所有 required 字段是否非空。即使单个 input.checkValidity() 为 true，只要父 fieldset 被禁用，整个表单就无效。
- 调试时优先查
document.querySelector("form").checkValidity()，而不是逐个字段验证 - 动态启用/禁用字段后，记得触发
dispatchEvent(new Event("input", {bubbles: true}))，否则浏览器可能缓存旧的 validity 状态 - 使用
FormData构造函数收集数据时，它会跳过disabled字段——但验证不跳过，这点极易导致逻辑错位
validity 对象直接操作 class 或 aria 的做法，迟早会在某个浏览器或辅助技术中露出破绽。大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
