1. 一次真实的卡顿现场：loading 转着转着就“冻住”了
1.1 现象表现与复现路径
先还原一下我当时遇到的问题。项目是一个典型的管理后台报表页，接口返回一张大列表，大概 8000 到 15000 行，每行有七八个字段，还要带状态标签、操作按钮这类子节点。页面交互并不复杂：用户点击“查询”，前端发异步请求，请求期间显示全局 loading，数据回来后把表格数据交给表格组件渲染。
问题很明确：loading 动画转个一两圈，突然卡住不动了，页面点哪里都没反应，浏览器标签页直接变成“无响应”状态，过个 3 到 5 秒才恢复正常。更糟的是，很多用户会在这段时间里重复点击查询按钮，等恢复后请求已经重复发了好几次，后端被白白打了好多遍。
我第一次排查时还以为是接口慢，后来看 Network 面板发现接口响应只要 400ms 左右，问题出在数据回来之后的渲染阶段。用 Chrome Performance 面板录了一段，真相一目了然：从数据赋值到表格渲染完成中间，主线程被一段长达 3.8 秒的 Long Task 占满，loading 的关闭逻辑、动画更新、事件响应全部排在后面排队。所谓“冻结”，其实就是主线程根本没空处理新任务。
这个场景其实非常常见，凡是做过管理后台、数据大屏、报表导出预览的人，大概率都撞过。根子在于：异步请求只是把数据从“服务器”搬到了“内存”，但把数据变成真实 DOM 这件事，依然全部压在主线程上。数据量一旦上去，主线程就变成单车道，什么车都堵在里面。
1.2 不是“网络慢”，而是“渲染线程窒息”
要理解这个现象，得先搞清楚浏览器渲染的基本流程。我在浏览器控制台里跑过一段性能采样，把问题拆成了三块：请求等待、数据处理、DOM 渲染。其中请求等待只占很小一部分，真正吃掉时间的是第三段。
页面里所有 JavaScript 执行、样式计算、布局（Layout）、绘制（Paint）都在主线程上。Global loading 本质上是一个依赖主线程持续调度的动画，按钮点击事件也需要主线程响应。当大数据渲染一次性同步执行时，JavaScript 引擎会在一个任务里连续完成：先把几千行数据的对象数组推入表格，再触发组件重新渲染，然后计算布局、绘制样式。浏览器虽然尝试把样式计算和布局拆成多个帧，但同步逻辑一次执行太久，主线程根本没机会插入新的任务，于是动画掉帧、点击监听无法触发、页面看起来就是“死了”。
我当时的项目里首屏表格用的是第三方数据表格组件，内部对数据做了深度响应式处理。8000 行数据传进去，光是响应式代理劫持和重渲染前的数据变更监听就花掉了不少时间。这部分工作在 Performance 面板里表现为一个巨大的紫色脚本块，后面跟着更长的紫色样式重算。所以别急着甩锅给表格组件，先自己测一下：同样数量的数据，用最简单的原生 Table 渲染会不会卡？
1.3 复现实验：数据量到多少开始“冻屏”？
为了把这个临界点找出来，我特意做了个小实验。同一台开发机、同一个空页面，分别渲染 1000、3000、5000、8000、10000 行表格，记录主线程最长任务时间和大致的阻塞时长。结果如下：
- 1000 行：几乎无感，Long Task 约 120ms
- 3000 行：能感觉到轻微卡顿，约 400ms
- 5000 行：loading 动画出现可察觉掉帧，约 900ms
- 8000 行：动画明显卡顿，约 1800ms
- 10000 行：页面出现短暂“无响应”，约 3000ms 以上
真正恶化的不是渲染本身，而是 DOM 数量增长之后，样式计算和布局的复杂度非线性上涨。表格每行都是十几个节点，1 万行就是 10 万+ 节点，浏览器在做样式匹配时要把整棵 DOM 树遍历一遍，数据一变，布局可能整体重排。所以这不是“稍微慢一点”，而是会跨过体验断崖，直接卡到用户怀疑人生。
2. 全局 loading 管理的真相：拦截器救不了渲染时序
2.1 常见实现方式：计数器 + 拦截器 + v-show
说回全局 loading 本身。我当时用的是很常规的方案：axios 请求拦截器里计数器加一，显示全屏遮罩层；响应拦截器里计数器减一，减到零就隐藏。这个思路本身没毛病，问题出在它只控制“请求阶段”的状态，对“渲染阶段”完全放任不管。
具体来说，正常流程是这样的：点击查询 → 拦截器 show loading → 请求发出 → 响应到达 → 拦截器把数据交给页面 → 页面同步 setState → 表格渲染 → 渲染完成后拦截器里的 hide loading 才执行。但实际上，响应拦截器里 hide loading 是在数据返回的同一时刻调用的，如果页面代码在数据回调里做了耗时的同步渲染，那 hide loading 的逻辑会被堵在后面，loading 遮罩层就会一直停在那里。
更麻烦的是，很多全局 loading 遮罩层是带 click 事件拦截的，本意是防止用户重复操作。结果主线程一卡，用户的点击事件全部积压，等主线程空闲后这些点击事件被依次派发，于是出现了“卡顿结束后自动发了一堆请求”的灵异现象。这根本不是网络问题，而是任务调度的直接后果。
2.2 核心矛盾：loading 的隐藏与渲染任务在抢主线程
我后来理了一下，可以把所有任务按优先级排个队：用户输入事件、动画帧回调、布局绘制、定时器、Promise 回调、网络回调。浏览器有一套自己的优先级规则，但对开发者来说，代码层面无法直接指定某个任务的优先级。也就是说，你没法说“先让 loading 关掉，再慢慢渲染表格”，你只能在代码结构上主动把渲染任务拆开，给 loading 留出喘息的空间。
因此，解决全局 loading 卡死的第一板斧，不是换一个更炫酷的 loading 组件，而是让 loading 尽量早点退场，别让它跟着渲染任务一起排队。两种思路：要么把渲染延迟到 loading 关闭之后，用两段式任务；要么把渲染拆成多个小任务，让浏览器在任务间隙有机会处理 loading 的关闭和动画。
我在项目里最初用的是后一种：把 hide loading 放在一个 setTimeout 0 里先执行，然后等一帧再渲染。简单有效，但治标不治本。数据稍微再涨一点，后续渲染照样卡。所以这一步只是铺垫，真正的重头戏在下面的数据加工和渲染调度上。
2.3 具体踩过的坑：遮罩层点击穿透与重复请求
这里值得展开说一下重复请求的坑。我的全局 loading 遮罩层是用 fixed 定位盖在整个页面上，正常情况下鼠标点击被遮罩挡住，不会穿透到底下的按钮。但主线程卡住时，浏览器并不会因为卡顿就把点击事件吞掉，它会先把事件放到队列里，等空闲了再派发。如果遮罩层因为在某些时序下提前被隐藏，那么积压的点击事件就会穿透到一个还没有完全解除绑定的按钮上，于是查询接口被连续触发。
后来我加了一道保险：查询按钮在点击后立即进入 disabled 状态，并且设了一个 1 秒的防重复标记，只接受第一次请求的结果，后面的重复响应一律丢弃。这个方案不依赖 loading 遮罩的拦截，彻底断了重复请求的源头。老实说，这比依赖 loading 层防误触可靠得多，项目上线到现在没再出现过重复提交的情况。
3. 把数据处理移出主线程：Worker 不是只能用来算哈希
3.1 不止排序和过滤，数据加工才是大头
很多人提到 Web Worker，第一反应是“可以用它做加密计算、复杂排序”。但在我这个场景里，数据加工逻辑比这重得多：接口返回的是扁平列表，页面需要把它构造成树形结构，加上状态码到文本的映射、标签的 className 生成、若干字段的拼接与格式化、日期转换、权限字段过滤。这一套走下来，几毫秒到几十毫秒不等，看着不吓人，但它和渲染连在一起，就变成了压垮主线程的最后一根稻草。
更关键的是，所有这些加工纯属“纯函数式操作”：输入是接口 JSON，输出是渲染所需的数组。它不碰 DOM，不依赖 window 上某些状态，非常适合放 Worker。我当时把表格数据加工的整段逻辑搬进 Worker 后，主线程只剩两件事：发数据过去、等结果回来。从代码结构上也清爽了很多。
3.2 实战示例：主线程只负责“发”和“收”
以我当时项目里的写法为例，先看主线程部分：
// 主线程 const worker = new Worker(new URL('./tableData.worker.js', import.meta.url), { type: 'module' }); let resolveTableData = null; worker.onmessage = (event) => { const processedList = event.data; if (resolveTableData) { resolveTableData(processedList); resolveTableData = null; } }; async function buildTableData(rawList) { return new Promise((resolve) => { resolveTableData = resolve; worker.postMessage(rawList); }); } // 业务层使用 const rawData = await fetchReportData(params); const processedData = await buildTableData(rawData); renderTable(processedData);Worker 内部则是这样的：
// tableData.worker.js import { formatDate, mapStatusToText, buildTree } from './processUtils.js'; self.onmessage = async (event) => { const rawList = event.data; const result = rawList.map((item) => ({ ...item, statusText: mapStatusToText(item.status), treePath: buildTree(item), dateText: formatDate(item.createTime), rowClass: getRowClassByStatus(item.status) })); self.postMessage(result); };这段代码里有一个值得注意的细节：不要在 Worker 里做和 DOM 渲染强相关的封装。比如我给每行生成一个“包含了完整 DOM 结构的模板字符串”这种做法看着省事，实际上把渲染逻辑完全绑定到了字符串上，后续要改表格列、调整样式，都得去 Worker 里改，反而难维护。Worker 只负责产出“更干净的 JS 数据”，DOM 结构还是交给主线程表格组件去生成。
3.3 序列化的代价：postMessage 不是免费的
别以为把数据处理丢给 Worker 就万事大吉了。主线程和 Worker 之间的数据传递需要结构化克隆，简单说就是数据要“复制一份”穿过线程边界。1 万行对象数组全量拷贝一次，大概也要几十毫秒。如果数据更大、对象嵌套更深，这个开销会非常明显。
我当时实测：1 万行数据 postMessage 过去大约耗时 35ms，处理完 postMessage 回来大约 25ms，整体多花 60ms 左右，但换来的是主线程从“卡死 3 秒”变成“稳定输出动画 60ms”。这个交换非常划算。
如果数据量继续涨到 5 万、10 万行，可以考虑给 Worker 传 ArrayBuffer 或 TypedArray，它们可以通过 Transferable Objects 转移所有权，不用复制内存。但前提是数据能用类型数组表示——表格这个场景里字段杂、带字符串对象，硬拆成类型数组会让代码复杂很多。我的建议是：2 万行以下用结构化克隆就行，别过度优化；真到 10 万行级别，再考虑用 ArrayBuffer 做列式存储，那通常是另一个量级的问题了。
4. 给渲染任务让路：时间切片与调度队列
4.1 为什么一次性渲染 1 万行不行，撕成片段就顺滑了
说实话，就算数据加工放进 Worker，主线程最后还是要做一件事：把几十 MB 的 JS 对象变成几千行真实 DOM。这是没法逃避的。问题只在于能否把它从“一个 3 秒的大任务”拆成“好多 20ms 的小任务”。
浏览器的渲染机制决定了：一个任务如果执行时间超过 50ms，用户就会感觉到卡顿；超过 100ms，动画开始掉帧；超过 300ms，基本就是“死屏”。所以目标只有一个：单次同步任务别超过 50ms，理想值控制在 20 到 30ms 以内。
方式其实很朴素。你可以把数据切成块，每次在事件循环间隙渲染一小块，渲染完一块就让出主线程，浏览器趁这个间隙处理动画、响应点击、更新 loading 状态。就像一卡车货物，你不该把它一股脑推进门里，而是一箱一箱搬，每一箱之间喘口气。
4.2 基础方案：requestIdleCallback 分批渲染
我最早实现了一个最简单的切片渲染器，核心逻辑就是：把数据按指定块大小切分，每渲染一块后，使用 requestIdleCallback 调度剩下部分，让浏览器在“空闲时段”继续。
const CHUNK_SIZE = 200; const tbody = document.querySelector('#table-body'); function renderChunk(list, startIndex) { const endIndex = Math.min(startIndex + CHUNK_SIZE, list.length); const fragment = document.createDocumentFragment(); for (let i = startIndex; i < endIndex; i++) { const tr = document.createElement('tr'); tr.innerHTML = ` <td>${list[i].id}</td> <td>${list[i].name}</td> <td>${list[i].statusText}</td> `; fragment.appendChild(tr); } tbody.appendChild(fragment); if (endIndex < list.length) { requestIdleCallback(() => renderChunk(list, endIndex), { timeout: 1000 }); } } // 启动 renderChunk(processedData, 0);这个方案在大多数浏览器里表现良好，但我很快遇到了三个实际问题。
第一个问题是 requestIdleCallback 的触发时机。页面如果一直有交互、有动画，浏览器可能长时间认为“不空闲”，导致渲染迟迟不继续。虽然 timeout 参数可以作为兜底，但 timeout 单位是毫秒，触发时任务执行频率可能很猛。第二个问题是兼容性，一些 webview 环境不支持这个方法，需要降级到 setTimeout。第三个问题最隐蔽：如果用户滚动表格，浏览器又要布局又要绘画，而 requestIdleCallback 又插进来渲染新行，两者会打架。
所以后来我换成了更可控的 setTimeout 方案，自己管理队列，保证同一时间只有一批渲染任务在执行。
4.3 更可控的方案：自研一个简单的 renderTaskQueue
核心思路是：用 setTimeout 模拟任务调度，既不用依赖 requestIdleCallback 的“空不空闲”判断，又能把任务切得足够碎。每次只渲染一批，然后等一帧（大约 16ms）再继续。为了不让用户看到表格“一行一行长出来”，可以一次渲染 300 到 500 行，间隔控制在 20ms 左右，肉眼基本察觉不到渐次加载。
class RenderTaskQueue { constructor(options = {}) { this.chunkSize = options.chunkSize || 400; this.interval = options.interval || 20; this.queues = []; this.isRunning = false; } add(task) { this.queues.push(task); if (!this.isRunning) { this.next(); } } next() { if (this.queues.length === 0) { this.isRunning = false; return; } this.isRunning = true; const task = this.queues.shift(); task(); setTimeout(() => this.next(), this.interval); } } const renderQueue = new RenderTaskQueue({ chunkSize: 400, interval: 20 }); renderQueue.add(() => { renderChunk(processedData, 0); }); renderQueue.add(() => { renderChunk(processedData, 400); });用的时候要配合分片函数一起：
function renderDataInChunks(data) { const total = data.length; for (let i = 0; i < total; i += 400) { const start = i; renderQueue.add(() => { renderChunk(data, start); }); } }这套方案的好处是：调度完全可控，如果想优先渲染表格前 50 行（首屏可视区域），可以先把前 50 行单独切出来立即渲染，剩下的慢慢排队。如果用户滚动到底部，还可以动态调整后续批次的大小（比如滚到底部时把 chunkSize 调大，让“追数据”的速度赶上来）。
4.4 给 loading 的“最后一口气”：先关闭遮罩，再开工渲染
这里有个非常值得说的经验。我最初是等数据全部渲染完才关闭 loading，结果时间切片后总渲染时间还是有个一两秒，loading 遮罩就这么干巴巴地转一两秒，体验依然差。后来我调整了顺序：数据加工完成 → 立即关闭 loading → 等浏览器绘制一帧（requestAnimationFrame）→ 开始切片渲染。
为什么这一步重要？因为 loading 遮罩本身是覆盖在整个页面上的，它的存在会强制浏览器在渲染表格时先处理遮罩层的合成和隐藏动画。如果遮罩还在，页面在视觉上会经历“遮罩消失 → 表格出现”的跳变；如果先把遮罩藏掉，再渲染数据，用户看到的就是“loading 消失 → 表格区域从空白到逐渐出现”，衔接自然很多。
实际执行时有个细节：不能直接把 hideLoading 和渲染放在同一个同步代码块里，因为两者还是同一个任务。我的做法是：
hideLoading(); requestAnimationFrame(() => { requestAnimationFrame(() => { renderDataInChunks(processedData); }); });双重的 requestAnimationFrame 是为了确保 loading 的隐藏动画至少渲染了一帧，遮罩已经从视觉上消失，然后再去碰表格 DOM。我用 Performance 面板验证过，这个双帧等待只增加 32ms 左右的延迟，非常值得。
5. 结构性解法：虚拟滚动和分页加载才是治本方案
5.1 什么时候必须上虚拟滚动
讲了这么多切片渲染，我必须坦诚地说一句：切片渲染只是“治标”，它让页面不卡了，但如果你一定要渲染 10 万行真实 DOM，再怎么切片，总量还是那么大，内存占用、滚动性能、筛选速度都不可避免地下滑。就拿我刚做的实验来说，1 万行表格渲染完成后的 DOM 节点数约 13 万，浏览器内存占用从 40MB 涨到 140MB。能渲染出来不代表这就是合理方案。
如果数据量预期超过 5000 行，且用户需要频繁滚动浏览，我的建议是直接上虚拟滚动。核心原理很直接：只渲染可视区域内的那一小部分行，比如视口里能放下 30 行，那就只渲染 30 行左右的 DOM，上下各留两行缓冲。滚动时动态替换这些行里的数据，而不是新建 DOM。这样不管数据是 1 万行还是 10 万行，DOM 数量恒定，渲染成本恒定，滚动性能完全可控。
我项目里有一张卡片式列表，每张卡片内容丰富，一次性渲染 3000 张卡也会卡，但用了虚拟列表后，实际 DOM 一直维持在 40 个左右，滚动再快也没卡过。
5.2 接口分页 + 前端增量加载：能不做大渲染就不做
除了虚拟滚动，还有一个更“偷懒”但非常有效的做法：请求时分页，前端做成“加载更多”或滚动触底加载。这个方法特别适合管理后台那种“用户其实看不完所有数据”的场景。用户真正关心的只是前几十条，与其硬灌一万条，不如先给一页 200 条，滚动到底了再拉下一页。
我当时在另一个项目里实践过这种方案：后端接口支持 size 和 page 参数，前端表格默认拉 200 条，滚动到底部时再拉下一页，追加到表格尾部。这种情况下根本不需要全局 loading，局部区域的加载指示器就够了。数据是慢慢长大的，用户感知不到卡顿，网络压力也小很多。唯一的代价是交互变复杂了，需要处理“追加加载中”状态和“全部加载完”状态。
那么三种方案怎么选？我给自己定了一个表，每次新需求来直接套用：
- 数据量 < 2000 行，且不会持续增长：常规渲染即可，预处理放 Worker。
- 2000 到 5000 行，或需要全部加载后做前端搜索排序：预处理放 Worker + 时间切片渲染。
- 5000 行以上，且用户要滚动浏览：直接虚拟滚动，不要犹豫。
- 只是“查一批看一批”，数据天然分页：接口分页 + 触底加载，永远别一次性全量渲染。
5.3 “数据加工重”和“DOM 渲染重”要分开评估
我后来发现，性能瓶颈往往不是单一来源，而是数据加工和 DOM 渲染叠加。同样的 1 万行数据，如果加工逻辑里有一个 O(n²) 的循环，哪怕只有 1000 行数据也可能卡；反过来，如果数据加工很轻，但 DOM 结构特别复杂（比如每行都嵌套折叠面板），1000 行也可能卡。所以方案选型之前，先分别评估两个环节的耗时：
- 打开 Performance 面板，录制一段脚本执行块，看“脚本”时长里是纯数据逻辑占比高，还是 DOM 操作占比高。
- 如果纯数据逻辑占了一半以上，优先上 Worker 把数据处理挪出去。
- 如果 DOM 操作占了大头，优先上虚拟滚动或分页，切片只是临时补救。
我见过一种很常见的错误做法：数据加工只有 50ms，却为了这 50ms 引入了特别复杂的 Worker 通信层，结果光通信就花了 80ms，得不偿失。所以别一股脑全上，先测量，再决定。
6. 实测结果与优化后的那些“新坑”
6.1 优化前后的指标对比
这套组合拳打完之后，我在同样的开发机上重新录了一遍 Performance，数据如下：
- 优化前：主线程最长 Long Task 约 3.8 秒，loading 卡死，期间点击事件全部积压，用 Chrome 自带的 FPS 大盘显示页面帧率跌到接近 0。
- 优化后：主线程最长同步任务降到 45ms，没有超过 50ms 阈值的卡顿，loading 正常完成“旋转 → 淡出”动画，点击响应恢复正常。表格数据从“请求返回”到“渲染完成”总耗时大约从 3.8 秒变成了 2.1 秒，单看总时长并没有缩短太多，但体验完全不一样了——用户眼里这是“流畅地逐渐出现”，而不是“死机后突然弹出来”。
其中 Worker 数据加工大约省了 300ms 主线程时间，切片渲染把剩余的大任务切碎，交互响应始终保持在用户可感知的流畅范围。
6.2 切片渲染带来的新坑：用户看到表格“一行一行长出来”
优化不是没有代价的。切片渲染最直接的副作用是：如果数据量特别大且切块粒度太粗，用户会看到表格“像输液一样”一行一行滴进来，视觉上不够从容。这个问题在数据量 > 5000 行时尤其明显。
我的解决办法是组合优化：首屏可见区域（大约前 50 行）立即渲染，无延迟；剩余数据的分批渲染间隙故意留得短一点（比如 12ms 而不是 20ms），让表格长得足够快，几乎无法被肉眼察觉。另外，渲染期间给表格容器加一个最小高度，避免因为内容未填满导致滚动条跳来跳去，这点特别重要——滚动条一蹦，用户就知道下面还在“长”，观感很差。
6.3 requestIdleCallback 的兼容性和后台标签问题
上文提过 requestIdleCallback 的一个坑是后台标签页不执行。用户切到其他标签页再回来时，requestIdleCallback可能因为浏览器判定“页面不可见，不需要渲染”而迟迟不触发。我实测在部分浏览器后台标签里，数据渲染会被无限挂起，直到用户切回页面才继续。这在小数据量场景不明显，一旦到了要切分三四十批的时候，用户切走再回来，表格可能只渲染了一半，非常尴尬。
我最终选择的方案是：兼容性降级到 setTimeout + 事件循环判断，自己控制批量推进。这样不依赖浏览器“空闲不空闲”的判断，后台照样能推进，只是渲染速率慢一点，回来时通常已经渲染完了。
6.4 防重复请求永远要做，别指望齐 loading 遮罩层
最后再强调一次：全局 loading 遮罩是“视觉辅助”，不是“交互安全网”。只要存在异步请求 + 慢渲染的窗口，就存在用户重复点击的可能。你可以在遮罩上写几百行防穿透逻辑，都不如直接在按钮和请求层做幂等控制来得可靠。
我在查询按钮上的最终做法是：点击后立即置灰，请求期间重新赋值为“查询中”；请求完成后如果是用户主动触发的，恢复按钮；如果上一次请求还没结束就收到新的触发，直接忽略。配合一个单调递增的请求序号，后发请求的响应如果序号小于当前请求，一律丢弃，防止旧响覆盖新数据。
这套“三保险”做完之后，我几乎再没收到过“数据错乱”“重复提交”之类的线上反馈。
写到这里，这个问题的解法和背后思路基本都说清楚了。核心无非是三层：数据加工出主线程、渲染任务切成片、数据量太大就直接上结构性方案。如果以后再遇到类似页面卡顿，我的习惯是先开 Performance 面板录一段，看 Long Task 到底落在哪，再决定是搬 Worker 还是做切片还是上虚拟滚动——永远用数据说话，而不是凭感觉堆方案。
