调用 setCustomValidity('错误信息') 后必须配合 reportValidity() 或表单 submit 才触发原生红色气泡提示；传空字符串可清除错误；需结合 :invalid:user-invalid 控制样式，且确保用户已交互。
怎么用 setCustomValidity() 触发原生错误提示
浏览器自带的红色气泡提示，不是靠 CSS 模拟出来的，而是调用表单控件的原生验证 API。核心就是 setCustomValidity() —— 它不返回值，只改变元素的 validity.customError 状态，再配合 reportValidity() 或提交自动触发。
常见错误现象：调用了 setCustomValidity('必填') 却没弹出提示，是因为没触发验证流程；或者反复调用后提示消失不了，是因为传了空字符串（setCustomValidity('') 会清除错误状态）。
- 必须在
input、select、textarea等可验证元素上调用，div或按钮上无效 - 错误信息字符串非空时才标记为无效；传空串或
setCustomValidity('')是“解除错误”操作 - 单纯设错不会立即显示提示，得调
reportValidity()（手动验证），或等表单 submit 事件触发 - Chrome 和 Firefox 支持良好，Safari 对自定义消息的样式控制较弱（比如不能改字体大小）
emailInput.setCustomValidity('邮箱格式不对');
emailInput.reportValidity(); // 这行不能少
为什么 :invalid + :user-invalid 才能稳稳控制样式
只用 :invalid 会在页面加载时就匹配未填的必填项，导致用户还没输就看到红框——体验很怪。真正想“用户操作后才高亮”，得叠加 :user-invalid。
这个伪类是 CSS UI 规范里明确规定的：只有用户与字段交互过（focus + blur、输入后删除等），且验证失败，才会生效。
立即学习“前端免费学习笔记（深入）”；
-
:invalid匹配所有当前无效状态，不管用户有没有动过 -
:user-invalid是更安全的选择，但 IE 完全不支持，Edge 105+ 才稳定 - 生产环境建议组合写：
input:invalid:user-invalid，兼顾逻辑和渐进增强 - 别试图用 JS 动态加 class 模拟，会和原生验证冲突（比如清空错误后 class 还挂着）
submit 事件里阻止默认行为却没显示错误？检查这三点
很多人在 form.addEventListener('submit', e => { ... }) 里做校验，发现 e.preventDefault() 之后，setCustomValidity() 设了也不弹提示——因为原生提示只在浏览器默认提交流程中触发。
- 如果你自己接管了提交逻辑，就别依赖原生气泡，改用 JS 插入
<span class="error">xxx</span>更可控 - 真要保留原生提示，就别
preventDefault()，改用form.reportValidity()提前验证，返回false时浏览器会自动弹窗并阻止提交 - 注意：
reportValidity()会触发所有字段的验证，包括没修改过的，所以对性能敏感的长表单要谨慎
移动端点不到错误提示气泡？试试 inputmode 和 autocomplete
iOS Safari 常见问题：点击输入框后键盘弹出，但错误气泡位置偏移、甚至被遮挡。根源是移动端对表单控件的焦点管理和气泡定位依赖于语义化属性。
- 加上
inputmode="email"或inputmode="decimal"，能帮系统判断输入类型，提升软键盘匹配度，间接改善气泡定位 -
autocomplete="off"在某些安卓浏览器里会禁用原生验证，导致setCustomValidity()失效，慎用；如需关闭自动填充，改用autocomplete="new-password" - 不要给表单容器设
transform或position: fixed，气泡定位基于视口，变形会影响坐标计算
原生错误提示看着简单，但跨浏览器、跨设备的细节很多，最容易被忽略的是「用户是否真的交互过」这个前提——没 focus/blur、没输入、没离开字段，:user-invalid 就不会生效，气泡也不会出来。
