浏览器对 javascript 执行没有统一、标准化的硬性超时限制，但会通过“无响应脚本”机制主动干预严重阻塞主线程的长时间运行代码，具体阈值因浏览器和设备而异。
在 Web 浏览器中，JavaScript 是单线程运行于主线程（main thread）上的，这意味着一段同步、阻塞式代码（如密集循环或未优化的递归）若持续占用主线程过久，将导致页面完全失去响应——无法渲染、无法响应用户输入、无法处理事件。为保障用户体验，主流浏览器均实现了脚本执行健康监控机制，但其设计目标并非精确计时，而是检测“疑似无响应”行为。
实际行为：非固定超时，而是启发式干预
不同浏览器采用不同的启发式策略，不存在 W3C 或 ECMA 标准规定的统一最大执行时间。例如：
- Chrome：通常在脚本连续占用主线程约 10–30 秒 后触发“页面无响应（Aw, Snap!）”或弹出“停止脚本”提示（具体阈值受系统负载、内存压力、是否启用开发者工具等影响）；
- Firefox：默认在脚本运行约 20 秒 后显示“脚本运行时间过长，是否终止？”对话框；
- Safari：行为类似，但更依赖系统资源状态，可能在 10 秒左右介入；
- Edge（基于 Chromium）：与 Chrome 行为基本一致。
⚠️ 注意：这些数值不是 API 可读取的配置项，也不是严格计时器，而是浏览器内部基于事件循环停滞、UI 更新延迟、输入队列积压等多维度信号综合判定的结果。
示例：触发浏览器干预的典型代码
// ⚠️ 危险示例：同步阻塞 15 秒（实际应避免！）
console.time("blocking-loop");
for (let i = 0; i < 1e10; i++) {
// 空循环（仅作演示，真实场景中可能是复杂计算或未中断的递归）
}
console.timeEnd("blocking-loop"); // 可能根本执行不到这里该代码极大概率被浏览器中断，并弹出警告——但它不会抛出 TimeoutError，也不会自动 throw 异常；而是由浏览器 UI 层直接终止 JS 执行上下文，后续代码不再运行。
立即学习“Java免费学习笔记（深入）”；
正确应对方式：避免阻塞，拥抱异步与分片
与其依赖浏览器“兜底”，不如主动优化：
- ✅ 使用 setTimeout / requestIdleCallback 将长任务拆分为微任务或空闲时段执行；
- ✅ 利用 Web Workers 在后台线程处理 CPU 密集型计算，不阻塞主线程；
- ✅ 对循环/递归添加 AbortSignal 或手动检查中断条件（如 performance.now() 时间戳 + if (elapsed > 50)）；
- ✅ 启用 Chrome DevTools 的 Performance 面板 或 Long Tasks API 监控 >50ms 的任务，识别潜在卡顿点。
总结
浏览器不会为 JavaScript 设置全局、可预测的“最大执行时间”，但会以用户体验为优先，对明显卡死主线程的行为进行干预。这种干预是启发式、非标准、不可靠的防御机制，绝不能作为程序逻辑的控制依据。稳健的前端开发必须遵循响应式原则：将长任务异步化、分片化、工作线程化，确保主线程始终可快速响应用户交互与渲染帧。
