网页堆栈溢出（Stack Overflow）其实是网页个翻译误导。它本意是堆栈“调用栈溢出”，跟那个问答网站没半毛钱关系。溢出你写递归函数忘写退出条件，解决浏览器调用栈撑爆了，网页页面就白屏。堆栈或者你绑了个无限循环的溢出事件，内存被吃干抹净，解决标签页直接崩溃。网页

我上周修了个bug，堆栈客户说他们的溢出后台管理页面点几下就卡死。打开控制台一看，解决好家伙，网页一个setInterval里又套了个setInterval，堆栈每次触发都往数组里push数据，溢出数组越滚越大，最后浏览器直接罢工。这种问题不叫堆栈溢出叫什么？

解决分三步走。第一步，打开DevTools的Performance面板，录制操作，看哪段函数执行时间异常长。火焰图里那个又宽又高的柱子，就是罪魁祸首。第二步，看Console报错，如果出现“Maximum call stack size exceeded”，说明递归没写好。如果是“Out of memory”，那就是数据攒太多了。

定位到问题后，改法其实很粗暴。递归改成循环，或者加个深度计数器，超过阈值就return。定时器记得清掉，用变量存一下timerId，组件卸载或者页面隐藏时clearInterval。数据流方面，能用流式处理就别全量存内存里，后端分页接口不香吗？

但有些堆栈溢出是隐性的。比如你用了某个第三方库，它内部递归遍历DOM树，你页面结构嵌套太深，直接爆掉。这种情况你查自己代码查破头也查不出来。我上个月就遇到一个富文本编辑器，在特定内容下崩溃，最后发现是编辑器源码里有个正则表达式在极端输入下导致灾难性回溯，CPU飙到100%，内存跟着爆。

对付这种，只能换库或者给编辑器加内容长度限制。别指望能彻底修好别人的代码，绕过去才是正道。

还有种情况容易被忽略——CSS动画。你给元素加了无限循环动画，同时又在JS里不断修改它的样式，浏览器为了重绘会不断创建新的渲染层，最终GPU内存耗尽。这不算严格意义的堆栈溢出，但表现一样：页面卡死，白屏。检查方法很简单，把动画暂停，看页面还卡不卡。

真到万不得已，还有个土办法。给页面加个错误监听，window.onerror里捕获异常，然后自动刷新。这治标不治本，但至少能撑到你把问题找出来。

最后说句实在的，大部分堆栈溢出都是开发时图省事留下的债。写递归前先想想能不能用迭代，用全局变量前考虑下生命周期，加定时器时顺手写好清理逻辑。这些习惯养成了，你遇到堆栈溢出的概率会直线下降。真碰上了也别慌，控制台打开，Performance录一遍，Console看一遍，基本就能锁定问题。解决不了就搜报错信息，社区里多半有人踩过同样的坑。