网页显示系统处理异常

页面白屏，网页控制台里一行红字：Uncaught TypeError: Cannot read properties of undefined (reading 'map')。显示系统用户看到的处理是空白，开发者看到的异常是灾难。网页显示系统的网页异常，本质上就是显示系统浏览器在渲染管线某个环节掉了链子，而链条上的处理每一环——HTML解析、CSS计算、异常布局、网页绘制、显示系统合成——都可能成为故障点。处理

我见过最常见的异常一种：接口返回的数据结构变了，前端还在按老字段取值。网页比如一个商品列表，显示系统原本后端给的处理是{ list: [...] }，某天改成了{ data: { items: [...] } }。前端代码没同步更新，res.list.map直接炸掉，整个组件树卸载，页面从有到无，用户一脸懵。这种异常的特点是——本地开发环境正常，测试环境偶尔复现，生产环境必现。原因很简单：本地mock数据没改，测试环境灰度了一半，生产全量。

另一种更隐蔽：CSS加载失败或阻塞。浏览器解析到<link rel="stylesheet">时，如果这个请求卡住，后面的DOM构建和渲染会被推迟。用户看到的是长时间白屏，然后突然全部出现。更糟的是，如果CSS里有关键布局属性（比如display: flex），加载失败后页面虽然能显示，但布局完全错乱——元素堆叠、文字重叠、按钮跑到屏幕外。这种异常不会在控制台报错，但用户体验比报错还差。

还有一类来自第三方脚本。广告、统计、客服组件，任何一个加载超时或执行出错，都可能阻断主线程。我遇到过某统计SDK在DOMContentLoaded之前同步执行，内部又去操作尚未生成的DOM节点，直接抛错。这个错误被浏览器捕获后，后续的脚本队列全部暂停。页面看起来“半死不活”：部分内容渲染了，部分没有，交互完全没响应。查了半天，发现是第三方代码里一个document.querySelector返回了null，然后调用了它的style属性。

内存泄漏导致的显示异常更折磨人。单页应用跑上几个小时，页面越来越卡，最后整个标签页崩溃。用Performance面板录一段，发现DOM节点数持续上涨，事件监听器越积越多。原因可能是某个组件在mounted时绑定了window.resize，但destroyed时忘了解绑。每次路由切换，旧组件的监听器还在，引用的DOM已经脱离文档树但无法被GC回收。最终浏览器内存耗尽，渲染进程直接挂掉。

处理这些异常，光靠window.onerror不够。onerror捕获不到资源加载失败（比如图片、CSS、JS文件404），也捕获不到Promise里未处理的rejection。得配合window.addEventListener('error', handler, true)来抓资源错误，再用unhandledrejection事件兜底。但捕获到错误只是第一步——上报时得带上用户环境、页面路径、组件栈，否则拿到一堆Script error.根本没法定位。

实际项目中，我倾向于在路由层面做降级。某个页面组件渲染出错，就用ErrorBoundary包住，显示一个“当前模块加载失败，请刷新重试”的提示，而不是让整个应用白屏。同时，关键数据接口加一层超时和重试，避免因为一个请求挂起导致后续渲染全部阻塞。这些手段不能根治异常，但至少让用户知道发生了什么，而不是对着空白页面发呆。

网页显示系统的异常，说到底就是“预期”和“实际”之间的裂缝。代码预期数据存在，实际不存在；预期资源加载成功，实际超时；预期内存被回收，实际泄漏。裂缝一旦出现，渲染管线要么中断，要么产出错误结果。修裂缝的方法很多，但前提是——你得先知道裂缝在哪。

本文地址：http://www.79wt.cn/news/1305b1699853.html