表单submit事件不抛错，需监听invalid事件或调用reportValidity()捕获校验失败；fetch成功但业务失败需手动解析响应；三类错误（校验/网络/业务）须分开处理。
监听表单 submit 事件但没捕获到错误？
表单提交本身不抛出 JavaScript 错误，submit 事件默认不会因校验失败或网络问题触发 error 或 catch——它只是被浏览器拦截并静默阻止。真正需要监听的是「提交被阻断」的信号，而不是等待异常。
常见错觉：给 form 绑定 addEventListener('submit', ...) 后加 try/catch，结果什么也抓不到。因为 DOM 事件不是 Promise，也不走 JS 异常流。
- 校验失败（如
required、type="email"）会触发invalid事件，但仅在用户交互时（比如点击提交），且不会冒泡 - 调用
form.reportValidity()可主动触发校验，并返回false表示失败，此时能同步判断 -
submit事件处理器里调用event.preventDefault()是手动接管的前提，否则浏览器直接跳转或刷新
捕获原生表单校验失败的具体字段
invalid 事件只在单个无效 input 上触发，且不提供“整个表单是否有效”的快照。想定位哪个字段出问题，得靠事件目标和 validity 对象。
注意：invalid 不会在 form.submit() 调用时触发——它只响应用户行为（如 blur、submit 点击）。所以自动化测试或脚本提交时要改用 reportValidity()。
立即学习“前端免费学习笔记（深入）”；
使用 Puppeteer + Chrome 将 HTML 渲染为中文 PDF，自动处理图表等待、Tab 展开、动画、测高、白边消除、防分页，适用于看板、报表、网页和交互图表转 PDF。
- 监听
form的invalid事件没用，必须监听内部input、select、textarea -
event.target.validity包含具体失败原因：valueMissing、typeMismatch、tooShort等 - 多个字段同时无效时，
invalid会触发多次，每次对应一个元素，不要假设只触发一次
拦截 submit 后手动校验并收集所有错误
最可控的方式是：阻止默认提交 → 遍历所有可校验字段 → 调用 reportValidity() 或读取 validity → 汇总错误信息。
这样能绕过浏览器静默拦截逻辑，把校验变成显式、可调试、可上报的过程。
-
form.checkValidity()返回布尔值，但不触发 UI 提示（比如红框、气泡）；reportValidity()会触发提示，且返回相同布尔值 - 遍历时跳过
disabled或type="hidden"字段，它们不参与校验 - 对
fieldset[disabled]内的控件，其willValidate为false，需提前过滤 - 示例关键逻辑：
form.addEventListener('submit', e => { e.preventDefault(); const errors = []; for (const el of form.elements) { if (!el.willValidate) continue; if (!el.checkValidity()) { errors.push({ name: el.name, message: el.validationMessage, validity: el.validity }); } } console.log(errors); });
处理 fetch 提交后的业务错误（非网络层）
表单通过 fetch 提交后收到 HTTP 200，但后端返回 { success: false, errors: [...] } ——这类错误不会触发任何原生事件，纯属业务逻辑，必须手动解析响应。
容易忽略的是：即使 fetch 成功（即网络通、状态码 2xx），也可能需要根据响应体内容判定为“提交失败”。这时候的错误和 HTML5 校验无关，不能混为一谈。
- 不要只检查
response.ok，它只对应 HTTP 状态码，不反映业务结果 - 后端返回的
errors字段结构应尽量与表单字段名对齐，方便映射回 DOM 元素 - 把业务错误写入对应
input的setCustomValidity()，再调用reportValidity()，可复用浏览器 UI - 避免在
catch块里吞掉网络错误（如 TypeError: Failed to fetch），这类错误应单独分类记录
