表单提交白屏卡顿主因是原生submit触发页面跳转阻塞渲染，须用e.preventDefault()拦截，改用fetch/XHR异步提交，配合按钮置灰、加载文案、服务端响应压缩及前端校验降RTT。
表单提交时白屏卡顿，根本不是JS慢
低网速下表单提交后页面长时间白屏，大概率不是前端逻辑卡住，而是浏览器在等待服务器响应期间，阻塞了整个渲染管线。特别是传统 <form> 的 submit 行为会触发完整页面跳转，中间没有任何缓冲——用户点一下，就只能干等，直到新页面 HTML 返回并开始解析。
真正要解决的，是「让交互有反馈、让等待可感知、让请求不阻塞」。
- 禁用原生提交：必须加
e.preventDefault()，否则一切优化都无效 - 优先用
fetch或XMLHttpRequest发送，而非依赖<form method="post"> - 提交按钮立刻置灰 + 加载态文案（如“提交中…”），避免重复点击
- 服务端响应尽量控制在 100KB 以内，JSON 比 HTML 更轻量；若必须返回 HTML，启用 gzip/brotli 压缩
FormData 提交后拿不到 responseText？检查 Content-Type
用 FormData 提交时，如果后端返回 JSON 却在前端拿到空字符串或乱码，八成是服务端没设对响应头，或者前端没正确解析。
FormData 默认以 multipart/form-data 方式发送，这是浏览器原生行为，无法手动改成 application/json —— 所以你不能指望后端按 JSON 解析 body，也不能直接用 response.json() 除非后端明确返回 Content-Type: application/json。
立即学习“前端免费学习笔记（深入）”；
- 后端需显式设置响应头：
Content-Type: application/json; charset=utf-8 - 前端接收时别漏掉
.then(r => r.json())，不要直接读r.responseText - 若后端坚持返回 HTML 片段（比如渲染好的错误提示），可用
response.text()+DOMParser提取内容，但体积要严控
弱网下验证失败要秒回，别等服务器
低网速环境里，把校验全扔给后端做，等于让用户多等一次 RTT（往返时延）。邮箱格式、手机号长度、必填项空值这些，完全可以在前端即时拦截。
重点不是“要不要前端校验”，而是「校验逻辑是否与后端一致」。前后端规则错位，会导致用户输对了也被拒，体验比没校验还差。
- 用
input[type="email"]、required、pattern做基础约束，浏览器自动触发 UI 提示 - 复杂规则（如身份证号、银行卡号）封装成纯函数，前后端共用同一套正则或算法
- 离开焦点（
blur）时触发轻量校验，但别发请求；只有提交时才走网络校验（如用户名是否已被注册） - 所有校验失败信息必须内联显示在对应字段下方，别只靠 alert 或顶部 toast
prefetch 关键资源，但别 prefetch 整个登录页
<link rel="prefetch"> 在低网速下容易被误用：prefetch 登录页 JS/CSS，结果用户根本没点登录，白白浪费带宽；更糟的是，它会和主页面资源争抢连接数，反而拖慢首屏。
真正该 prefetch 的，是「提交后极大概率要加载的资源」，比如表单成功后的跳转页关键 JS，或通用的 loading 动画组件。
- 只 prefetch 静态资源（
.js、.css、.json），不 prefetch HTML 页面 - 加
as="script"或as="fetch"，让浏览器提前分配正确类型的加载通道 - 配合
crossorigin属性（尤其 CDN 资源），避免因 CORS 导致 prefetch 失败却无报错 - 用
document.querySelector('link[rel="prefetch"]').onload监听预加载完成，但别依赖它做功能判断
低网速优化最易被忽略的一点：所有「等待」都要有 fallback。比如 fetch 超过 3 秒没响应，就降级显示本地缓存的上次成功状态，而不是一直转圈。用户感知到的是「系统还在工作」，而不是「系统卡死了」。
