最直接的防刷新方案是监听form的submit事件并调用event.preventDefault()；次选target="iframe"兼容无JS场景；后端返回204可免JS但无反馈；localStorage仅用于防刷新丢数据。
用 event.preventDefault() 拦截 submit 事件是最直接的载体
表单提交刷新页面，本质是浏览器对 submit 事件的默认行为。不改 HTML 结构、不依赖后端，仅靠前端 JS 就能阻断——关键就是监听 submit 并调用 event.preventDefault()。
常见错误是只绑了 click 事件在按钮上，漏掉表单自身的 submit 事件（比如用户按回车也会触发）。必须监听 form 元素的 submit，不是按钮。
- 脚本需在 DOM 加载完成后执行，否则
document.querySelector('form')可能返回null - 如果表单动态插入（如模态框中），要用事件委托或在插入后立即绑定
- 别在
onsubmit="return false"里写逻辑——可读性差、调试困难、无法 async/await
target="iframe" 是无需 JS 的兼容性载体
当不能依赖 JavaScript（如老旧系统、严格 CSP 策略），或需上传文件且不希望 fetch 处理二进制流时，<iframe> 是唯一原生支持的无刷新载体。
原理很简单：把表单 target 指向一个隐藏 <iframe name="xxx">，浏览器就把响应载入 iframe，主页面不动。
立即学习“前端免费学习笔记（深入）”；
-
<iframe>必须有name属性，且和form的target值完全一致 - iframe 需设
style="display:none"或width="0" height="0"，避免布局干扰 - 后端返回内容会进入 iframe，若需通知主页面，得用
window.parent.postMessage跨 frame 通信 - 现代项目慎用——无法拦截请求、难做 loading 状态、不支持 Promise 链式处理
后端返回 204 No Content 是服务端协同载体
如果你控制得了后端，且表单是简单 POST（比如埋点、日志、通知），让服务器返回 204 状态码，浏览器就会“提交成功但不跳转”，连 JS 都不用写。
注意这不是万能解法：它不适用于需要响应体（如校验错误信息、新 token）的场景；也不能阻止页面跳转——前提是表单没加 event.preventDefault()，否则根本不会发请求。
- 必须确保
form没被 JS 拦截，即没调用preventDefault() - 后端设置
ctx.status = 204（Koa）、response.status(204)（Express）即可，无需res.send() - 前端无法感知成功与否，也没法做 UI 反馈，纯靠服务端日志确认
localStorage + 页面加载回填不是提交载体，而是防刷新丢失的补救措施
很多人混淆“防止提交刷新”和“防止刷新丢数据”。前者是阻断行为，后者是数据兜底。即使你用 preventDefault() 拦住了提交，用户手抖 F5，输入框还是空的——除非你提前存。
真正起作用的是：在 input、textarea 的 input 事件里，把值写进 localStorage；页面加载时，用 DOMContentLoaded 读出来并 .value = 回填。
- 键名必须带上下文，比如
form-login-username，避免多个表单冲突 -
disabled字段不会被FormData收集，也不会自动存，得单独监听其变化 - 动态增删的字段（如地址列表项），每次 DOM 变更后都要同步更新 storage 键值对
- Safari 无痕模式禁用
localStorage，可 fallback 到sessionStorage，但关 Tab 就清空
FormData + fetch），又要求输入即存（要监听所有字段），还要兼容旧 IE（得降级到 iframe）。这时候得按优先级分层处理——先保核心功能可用，再叠加体验优化。 
