页面卡住那一刻，网站未响为脚浏览器给的应因运行提示往往只有一句：“网站未响应，因为脚本长时间运行”。本长很多人第一反应是时间网速差，刷新几次，网站未响为脚甚至重启路由器。应因运行其实问题常常不在网络，本长而在浏览器执行 JavaScript 时被一段代码拖住了。时间

浏览器的网站未响为脚主线程一次只能做一件事。渲染页面、应因运行响应用户点击、本长执行脚本，时间都排在同一队列里。网站未响为脚某段脚本如果一直占着主线程不放，应因运行页面就没法重绘，本长按钮也点不动。Chrome 在检测到某个任务超过一定时间仍未让出控制权时，就会弹出那个对话框，问你是继续等待还是结束页面。

我遇到过最典型的一次，是后台管理系统里一个表格页面。数据量大概两万行，前端为了做“实时筛选”，在每次输入时都遍历整个数组，还在循环里反复操作 DOM。表面上看只是输入框里敲了一个字，实际却触发了上万次计算和重排。浏览器撑了三四秒后直接卡死，控制台没有报错，网络面板也看不出异常。最后用 Performance 面板录制才定位到，问题出在一个看似无害的 filter 加 innerHTML 的组合上。

脚本长时间运行的原因不复杂，但种类不少。死循环是最直接的一种，比如 while(true) 忘了写退出条件。递归没有边界也会把调用栈撑爆，不过那种通常会直接抛错，反而不会让页面一直转圈。更隐蔽的是大量同步计算、密集的 DOM 操作、或者在一个事件回调里做了太重的事情。比如滚动事件里每次触发都去读取 offsetTop，强制浏览器同步布局，滚动稍微快一点就卡成幻灯片。

还有一种情况容易被忽略：第三方脚本。广告、统计、客服插件，随便哪一个在加载后执行一段低效代码，都能让整个页面遭殃。你自己的代码写得再干净，也架不住别人在你页面里跑一个 O(n²) 的循环。

浏览器其实给了开发者机会。Web Worker 可以把耗时计算挪到后台线程，主线程只管更新界面。requestAnimationFrame 和 setTimeout 能把长任务切成小片，每执行一小段就交还控制权。分页、虚拟滚动、防抖节流，都是针对这类问题的常规手段。关键是要意识到：主线程是稀缺资源，不能随便挥霍。

普通用户碰到这个提示，能做的有限。等几秒，如果页面恢复，说明脚本只是慢，不是死。如果一直没反应，只能关掉标签页重开。真正该负责的是开发者。上线前用 Lighthouse 跑一遍，或者手动在低端设备上试试，很多问题在开发机上根本暴露不出来。毕竟你的电脑跑得飞快，不代表用户的手机也扛得住。

那个提示框本身挺粗暴的，但它说了一句实话：脚本确实跑了太久。浏览器没冤枉谁。