preventdefault() 会禁用浏览器原生验证提示，必须手动实现错误提示、清理、聚焦和可访问性支持。
submit 事件里 preventDefault 后，错误提示不显示？
常见现象是：表单提交时做了 event.preventDefault()，也调用了 setCustomValidity() 或手动添加了 span 提示，但用户根本看不到任何反馈——不是没触发，而是提示被浏览器默认行为覆盖或 DOM 更新时机不对。
根本原因是：浏览器原生验证（比如 required、type="email"）只在原生 submit 流程中自动展示气泡提示；一旦你用 preventDefault() 拦截，这套机制就失效了，必须自己接管所有提示逻辑。
- 不要依赖
input.reportValidity()后的原生气泡——它只在未被拦截的 submit 中可靠 - 手动提示建议统一插入到对应
input的相邻位置（如nextElementSibling），并用aria-live="polite"保证读屏器可感知 - 校验失败后，记得给焦点出错字段加
focus()，否则用户可能不知道哪错了
用 checkValidity() 和 setCustomValidity() 为什么没反应？
这两个 API 看似简单，但实际生效有隐含前提：它们只影响当前元素的「原生验证状态」，不会自动触发 UI 反馈，也不会阻止表单提交——除非你在 submit 事件里显式调用 form.checkValidity() 并配合 preventDefault()。
典型误用：只对某个 input 调用 setCustomValidity("不能为空")，但没在表单级做拦截和检查，结果提交照常发生。
立即学习“前端免费学习笔记（深入）”；
动态WEB网站中的PHP和MySQL详细反映实际程序的需求，仔细地探讨外部数据的验证(例如信用卡卡号的格式)、用户登录以及如何使用模板建立网页的标准外观。动态WEB网站中的PHP和MySQL的内容不仅仅是这些。书中还提到如何串联JavaScript与PHP让用户操作时更快、更方便。还有正确处理用户输入错误的方法，让网站看起来更专业。另外还引入大量来自PEAR外挂函数库的强大功能，对常用的、强大的包
-
setCustomValidity("")才代表“通过”，非空字符串才代表“失败” - 修改
setCustomValidity后，必须再调一次checkValidity()或触发一次验证（如 blur、submit）才会更新:invalid伪类 - 多个字段同时校验时，别只检查第一个——要用
Array.from(form.elements).every(el => el.checkValidity())
后端返回 400 错误，前端怎么把字段级错误塞进表单？
这是前后端协作最易出问题的一环：后端返回的错误结构（如 {"email": ["已被注册"], "password": ["至少8位"]}）和前端 DOM 字段名不一致，或没清理旧提示，导致错误堆叠、定位错乱。
关键不是“怎么显示”，而是“怎么映射”和“怎么清理”。建议把后端字段名和表单 name 属性严格对齐，并为每个字段预留固定提示容器。
- 服务端字段名必须和
input[name]完全一致（区分大小写、下划线/驼峰） - 每次渲染新错误前，先清空所有已有提示：
form.querySelectorAll(".error-message").forEach(el => el.remove()) - 提示容器建议用
<span class="error-message" aria-live="assertive"></span>，紧跟在对应input后面 - 避免用
alert()或全局 toast 替代字段级提示——用户需要知道“哪个字段错在哪”
移动端 iOS Safari 上验证气泡不出现？
iOS Safari 对原生验证气泡支持极不稳定，尤其在 modal、fixed 容器或使用了 transform 的布局中，气泡常被裁剪、偏移甚至完全不触发。这不是 bug，是它的渲染策略限制。
真实可行的做法是：在 iOS 上主动降级，禁用原生气泡，全程走自定义提示。检测方式很简单，不用 UA 判断，直接用特性检测。
- 用
"reportValidity" in HTMLFormElement.prototype判断是否支持原生报告（iOS 15.4+ 才稳定） - 更稳妥的是监听
input的invalid事件，然后立即preventDefault()并手动提示——这能绕过气泡渲染问题 - 避免在
position: fixed或transform容器内放表单，iOS 的气泡定位会彻底失准
