html表单不支持长轮询，因其默认短连接提交机制与长轮询需持续持有连接的特性冲突；正确做法是禁用默认提交，提取表单数据后用fetch+abortcontroller手动实现循环请求。
HTML 表单本身不支持长轮询
表单提交是短连接行为，submit 触发后浏览器立刻发起一次 HTTP 请求并等待响应，完成后页面跳转或刷新（除非用 event.preventDefault() 拦截）。长轮询需要持续持有连接、手动管理请求生命周期——这和表单原生机制冲突。
常见错误现象：fetch() 或 XMLHttpRequest 发起长轮询后，用户仍点击表单按钮，导致重复请求、状态错乱、甚至 400 Bad Request（因表单数据被重复序列化）。
- 真正该做的是：把表单数据提取出来，交给自定义的长轮询逻辑处理
- 禁用表单默认提交行为，用
FormData或手动收集字段值 - 避免在
onsubmit里直接调用长轮询函数却不阻止默认行为
用 fetch 实现带表单数据的长轮询
fetch() 默认不支持超时控制和连接保持，但可通过 AbortController 和循环重连模拟长轮询。关键不是“发一次”，而是“等响应 → 处理 → 立即发下一次”。
使用场景：后台任务状态轮询（如文件上传进度、AI 推理结果）、轻量级消息推送（无 WebSocket 条件下）。
立即学习“前端免费学习笔记（深入）”；
- 必须设置
timeout（用AbortController），否则请求可能永久挂起 - POST 数据推荐用
JSON.stringify()+Content-Type: application/json，比FormData更易服务端解析（尤其 Node.js/Python 后端） - 服务端响应必须及时返回（即使无新数据），否则客户端会卡住；典型做法是返回
{ status: "pending" }或空 body
const controller = new AbortController();
const signal = controller.signal;
async function poll() {
try {
const res = await fetch("/api/task-status", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ task_id: "<code>123</code>" }),
signal
});
const data = await res.json();
console.log(data);
setTimeout(poll, 1000); // 下一轮
} catch (err) {
if (err.name !== "AbortError") console.error(err);
}
}
jQuery.ajax 长轮询容易踩的坑
老项目还在用 jQuery？$.ajax() 的 timeout 和 abort() 行为不如原生 fetch 直观，且默认会缓存 GET 请求（GET 长轮询必须关掉）。
-
cache: false必须显式设置，否则 IE/旧 Chrome 可能复用上一次响应 -
timeout值要略小于服务端超时（比如后端设 30s，前端设 25s），留出网络延迟余量 - 不要在
success回调里直接递归调用自身，容易堆栈溢出；改用setTimeout延迟触发 -
error回调中需判断jqXHR.status === 0（网络中断）还是具体 HTTP 错误码，决定是否重试
服务端响应格式影响前端重连逻辑
前端长轮询是否稳定，一半取决于服务端怎么回。如果每次响应都返回 200 OK 但内容是 {"code":500,"msg":"timeout"}，前端就很难区分“真错误”和“正常等待”。
- 推荐约定：有数据则返回
200+ 实际 payload；无更新则返回204 No Content或304 Not Modified - 避免用
504 Gateway Timeout表示轮询超时——这是网关层错误，语义不对，前端不该据此重试 - 响应头加
Cache-Control: no-store，防止中间代理缓存“空响应”
复杂点在于：长轮询不是开个定时器发请求那么简单，它要求前后端对“连接语义”有一致理解。最容易被忽略的是服务端未及时关闭空闲连接，导致大量 TIME_WAIT 占满端口，或者前端没做 abort 清理，切换页面后还在后台发请求。
