表单提交前怎么根据条件走不同逻辑
不能靠一个 submit 事件硬塞所有判断，得把“是否提交”和“提交去哪”拆开。用户点提交按钮时，你得先决定：是直接发请求？跳转页面？弹窗确认？还是拦下来改字段？
常见错误是把所有分支写在 form.onsubmit 里用 if/else 堆砌，结果某个分支漏了 return false，表单照常提交；或者用了 event.preventDefault() 却忘了手动触发后续动作。
- 用
event.preventDefault()拦住默认提交行为，这是所有分支的起点 - 每个分支最后必须显式调用
fetch()、location.href或form.submit()（注意：后者会绕过 JS 验证） - 避免在分支里混用同步跳转和异步请求——比如一个分支
location.replace()，另一个分支await fetch()后更新 DOM，用户感知会割裂
多个按钮对应不同提交目标怎么办
别给每个按钮都绑 click 再手动收集表单数据。HTML 原生就支持：用 formaction 属性直接指定该按钮的提交地址，浏览器自动覆盖 <form></form> 的 action。
场景比如「保存草稿」和「正式提交」共用同一组字段，但后端接口不同；或者「预览」按钮需要把数据发到渲染服务而非保存接口。
立即学习“前端免费学习笔记（深入）”；
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
<button type="submit" formaction="/api/draft">存草稿</button><button type="submit" formaction="/api/submit">正式提交</button>- 注意：
formaction的值会完全替换<form></form>的action，包括 query 参数，不要指望它拼接 - 如果需要传额外参数（如
?mode=preview），得用formaction写死完整 URL，或改用 JS 控制
表单验证失败后怎么只高亮出问题字段
别用 alert() 或全局提示框糊弄用户。现代做法是让浏览器原生验证（required、type="email"）配合 :invalid CSS，再加一层 JS 补位。
容易踩的坑是：手动调用 checkValidity() 后，只改了样式却没调用 reportValidity()，导致用户看不到浏览器自带的气泡提示；或者在 input 事件里频繁触发验证，卡顿且干扰输入。
- 监听
submit事件，在里面调用form.checkValidity() - 验证失败时，立即执行
form.reportValidity()，它会触发原生提示并聚焦第一个无效字段 - 如需自定义高亮（比如加红边框），用
form.querySelectorAll(':invalid')批量操作，别逐个字段判断 - 避免在
input或blur里调用reportValidity()，用户还没输完就报错体验极差
后端返回不同状态时前端怎么分流处理
不是所有响应都该跳转或清空表单。比如「邮箱已注册」要留着用户填的其他字段，「支付超时」要允许重试，「网络错误」得给重试按钮——这些都得靠响应体里的字段区分，而不是 HTTP 状态码。
很多人直接写 if (res.status === 200)，结果后端用 200 包所有情况（含业务失败），前端彻底失控。
- 约定后端响应结构统一含
code字段（如200成功，409冲突，500服务异常） - 前端用
switch(res.data.code)分支，而不是if (res.ok) - 对可恢复错误（如
code: 429频率限制），保留表单数据并启用重试按钮；对不可恢复错误（如code: 400参数错误），聚焦第一个报错字段并显示提示 - 网络层异常（
fetch抛错、AbortError）必须单独捕获，不能混进业务catch里处理
最麻烦的其实是表单里嵌了动态组件（比如地址选择器、文件上传区），它们各自有状态，主表单提交时得协调好时机——不是所有子状态都适合在 submit 事件里强行读取。
