fetch无原生timeout参数，必须用AbortController+Promise.race实现真超时：新建controller、传signal、设setTimeout abort、race竞争出口，并检查err.name==='AbortError'。
HTML 本身无法处理 fetch 超时——form 标签没有超时属性，fetch() 本身也不认 timeout: 5000 这种写法。真正可行的路径只有一条：用 JavaScript 拦截表单、手动生成 fetch 请求，并通过 AbortController 主动中止。
为什么 fetch(url, { timeout: 5000 }) 完全无效
这不是浏览器 bug，而是规范没定义这个字段。Chrome、Firefox、Safari 都会静默忽略它，请求照常挂起，直到底层 TCP 超时（通常 2–5 分钟），用户卡在白屏却无反馈。你看到的“超时错误”大概率是服务端返回的 408 或 504，和前端控制无关。
-
timeout不在 Fetch API 规范里，任何教程里出现这个写法，要么过时，要么误导 - 即使某些实验性环境（如旧版 Chromium 内部构建）偶然支持，也绝对不能上线依赖
- 仅靠
setTimeout(() => reject(new Error()))无法终止网络请求，后续响应仍可能触发then或catch，引发竞态问题
必须用 AbortController + Promise.race 实现真超时
这是目前唯一能真正中断进行中请求、且被 Chrome 66+ / Firefox 57+ / Safari 12.2+ 广泛支持的方式。核心不是“等超时”，而是“发信号让 fetch 主动退出”。
- 每次请求都得新建
AbortController实例，复用会导致多个请求被同一个abort()意外中止 -
signal: controller.signal必须传进fetch的options，缺了就不起作用 - 用
Promise.race([fetch(...), timeoutPromise])控制出口，避免await fetch卡死主线程 -
catch里要检查err.name === 'AbortError'，不能只看err.message是否含 “timeout”
function fetchWithTimeout(url, options = {}, timeout = 8000) {
const controller = new AbortController();
const timeoutPromise = new Promise((_, reject) =>
setTimeout(() => reject(new Error('Request timeout')), timeout)
);
return Promise.race([
fetch(url, { ...options, signal: controller.signal }),
timeoutPromise
]);
}
表单提交场景下最容易漏掉的三件事
用 fetch 替代原生表单提交时，超时逻辑极易崩坏，尤其在用户快速连点或页面跳转时。
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
立即学习“前端免费学习笔记（深入）”；
- 没调
event.preventDefault()：表单仍会走传统提交路径，导致页面跳转 +fetch双重发送 - 没在
submit事件里新建AbortController：复用旧实例会让后续请求被前一次超时误杀 - 没处理页面卸载：用户关闭标签页时，
controller.abort()可能来不及执行；可加window.addEventListener('beforeunload', () => controller.abort())补一刀（注意该事件中不能await）
兼容 IE 或老安卓 WebView 的降级方案
AbortController 在 IE 中完全不可用，Android 4.x WebView 也基本不支持。此时只能放弃“真正中止请求”，退为“逻辑超时”：
- 用
Promise.race包裹fetch和定时器，超时后拒绝 Promise，但已发出的请求仍在后台跑 - 务必和服务端协同：前端设 8s 超时，Nginx 的
proxy_read_timeout至少设 10s，留出网络抖动余量 - 后端接口需幂等（尤其 POST/PUT），否则逻辑超时后用户重试可能造成重复提交
真正难的不是写那几行 AbortController 代码，而是每次请求都记得新建实例、每次 catch 都检查 AbortError、每次表单提交都确认 preventDefault —— 这些细节一漏，超时逻辑就形同虚设。
