用 fetch + setTimeout 轮询查状态最稳，先提交获取 task_id，再以此轮询 /api/status 接口；需禁用按钮、指数退避、设最大重试和总超时、清理定时器、处理页面可见性及 DOM 安全。
表单提交后怎么轮询查状态？用 fetch + setTimeout 最稳
轮询不是靠表单自己完成的，而是提交成功后，用 JS 主动发起多次请求去查后端接口。关键在「提交和轮询解耦」：先发一次提交，拿到一个任务 ID（比如 task_id），再拿它去轮询 /api/status?task_id=xxx。
常见错误是把轮询逻辑写在表单 onsubmit 里，没阻止默认提交，结果页面跳走了；或者轮询没设上限，网络卡住就无限等下去。
- 提交后立刻禁用按钮，防止重复点击：
button.disabled = true - 轮询间隔建议从 1s 起步，失败或超时后逐步加长（比如 1s → 2s → 4s）
- 必须设最大重试次数（比如 10 次）和总超时（比如 60s），否则用户关掉标签页都停不下来
- 后端返回的状态字段要明确，比如
{ "status": "processing" | "success" | "failed", "result": ... }，别只靠 HTTP 状态码判断
轮询时怎么避免浏览器卡死或内存泄漏？
频繁 setTimeout 或 setInterval 不清理，容易让旧轮询还在跑，新轮询又启动，多个定时器叠加。更麻烦的是，如果用户切走标签页，setTimeout 在部分浏览器里仍会执行（尤其 Chrome 后台节流不彻底）。
- 每次发起新轮询前，先
clearTimeout上一次的句柄 - 用一个变量存当前轮询 ID（比如
let pollId = null），每次赋新值前清旧值 - 监听
visibilitychange事件，在页面不可见时暂停轮询，可见后再恢复（或直接终止） - 不要在轮询回调里直接操作 DOM 元素而不检查是否存在，比如
document.getElementById('status')返回 null 时继续 .innerText = ... 就会报错
XMLHttpRequest 还能用吗？和 fetch 有啥实际差别？
能用，但没必要。除非你得支持 IE10 以下——现在基本没有这种场景了。fetch 更轻、可取消（配合 AbortController），错误处理也更符合直觉（注意：网络失败才 reject，HTTP 4xx/5xx 仍是 resolve）。
立即学习“前端免费学习笔记（深入）”；
-
fetch默认不带 cookie，轮询要查登录态就得加{ credentials: 'include' } -
XMLHttpRequest的timeout是原生支持的，fetch得靠AbortController+setTimeout模拟 - 如果后端返回非 JSON（比如纯文本或空响应），
fetch的.json()会直接 throw，得包try/catch，而XMLHttpRequest的responseText更“宽容”
后端接口设计不配合怎么办？比如没返回 task_id 或状态字段模糊
前端轮询的前提是后端提供可识别、可轮询的标识和状态语义。如果提交接口只返回 { "ok": true }，或者状态字段叫 code 却不文档化取值含义，轮询就会变成猜谜。
这时候别硬扛，优先推动后端改。实在不行，只能妥协：
- 用时间戳 + 用户 ID 拼接成伪
task_id（风险高，仅临时应急） - 轮询接口返回空或 404 当作“还没好”，200 且有数据当作“好了”——但这无法区分“失败”和“还没生成”，容易误导用户
- 加一层前端缓存：同一表单提交，10 分钟内相同参数不再轮询，直接返回上次结果（需后端支持幂等）
真正难的从来不是写几行轮询代码，而是状态定义是否清晰、前后端约定是否落地。漏掉这一环，JS 写得再漂亮，也会在某个凌晨三点因为一个 status === "done" 实际该是 "completed" 而出问题。
