你碰到的这个2分钟超时是Chrome和Firefox的内置硬限制——浏览器为了避免长期占用资源，默认给网络请求设了这个阈值，而且没法直接通过Fetch API的参数修改。不过有几个办法能处理这个问题，甚至实现自定义超时逻辑：

1. 手动封装带自定义超时的Fetch（前端层面） #

用Promise.race()可以把原生Fetch和一个定时器Promise结合，自己控制超时时间。比如要设置5分钟超时，代码可以这么写：

// 封装带超时的fetch函数
const fetchWithTimeout = (url, options, timeoutMs = 300000) => {
  // timeoutMs默认设为5分钟（300000毫秒）
  return Promise.race([
    // 原生fetch请求
    fetch(url, { ...options, credentials: 'include' }),
    // 超时定时器
    new Promise((_, reject) => {
      setTimeout(() => reject(new Error('请求超时：超过设定的等待时间')), timeoutMs);
    })
  ]);
};

// 使用示例
const formData = new FormData();
// 这里填充你的formData内容
formData.append('key', 'value');

fetchWithTimeout('你的服务器接口地址', { method: 'POST', body: formData })
  .then(res => {
    if (!res.ok) throw new Error('服务器响应异常');
    return res.json();
  })
  .then(data => console.log('请求成功:', data))
  .catch(err => console.error('请求失败:', err));

⚠️ 注意：就算你把超时设得很长（甚至去掉定时器实现“无限等待”），浏览器底层的网络栈还是会有自己的硬限制（就是你碰到的2分钟左右），这个是前端代码没法突破的。

2. 后端异步处理（解决根本问题） #

如果你的业务真的需要3分钟以上的响应时间，前端的办法只能治标，建议后端改成异步模式：

• 前端发送请求后，后端立刻返回一个任务ID，告诉前端“我收到请求了，正在处理”
• 前端用这个任务ID定期轮询（比如每30秒发一次请求），查询任务处理状态
• 当任务完成后，后端把结果返回给前端

这种方式不仅避开了浏览器的超时限制，还能给用户更好的体验——比如可以在页面上显示“处理中”的状态，而不是让用户一直等空白页面。

另外提一下你说的Firefox重发请求的问题：这是Firefox内置的连接重试机制，当第一次请求超时后，它会自动重试一次，这个行为同样没法通过前端代码关闭。

内容的提问来源于stack exchange，提问作者Cichelero