最近一次拖拽从约 秒降到了 秒耗时减少约 %。

这篇文章就完整记录一下：这么一个看起来普普通通的拖拽。为什么会卡，还有我是怎么一步步找到真正原因的。

一、先来看一下这个需求

页面布局大概是这样的：

• 左侧展示成果文件表格；
• 右侧展示文件预览；
• 中间有一根拖拽手柄；
• 手柄向左拖，预览区域变宽；
• 手柄向右拖，预览区域变窄；
• 松手后需要记住宽度，下次打开继续使用。

普通文件看起来还好。但是当左侧表格有多行数据，右侧又打开一个长文本预览时拖拽就开始明显卡顿。

我一开始很自然地怀疑到了右侧预览。怎么说呢，

毕竟文本预览有语法高亮。行文本会生成很多 DOM 节点。DOM 可以简单理解为浏览器页面中的元素结构。节点越多，浏览器处理布局和绘制时需要考虑的东西也就越多。

但怀疑归怀疑，还是得先想办法稳定复现。

二、不要靠手感调整，先搞一个能反复执行的复现

性能问题最怕的就是：

这种“好像”基本不太可靠。今天电脑负载低一点，或者自己心里觉得改过了都会让拖拽看起来更流畅。

当时真实后端正好不可用，开发页面返回了 HTTP 。为了继续排查，我临时启动了一个最小模拟后端。只提供这次复现需要的数据：

• 条成果文件记录；
• 一个包含 行内容的文这篇文章件；
• 页面启动所需的几个基础接口。

这样数据虽然是模拟的，但是页面仍然使用真实的成果库表格、真实预览组件和真实拖拽逻辑。

接下来固定测试动作：

1. 打开成果库；
2. 打开一个 行文本预览；
3. 使用 个连续拖拽点；
4. 将分隔线移动 180px；
5. 记录整个拖拽动作的耗时。

第一次跑出来的结果约为 秒

const handleMouseMove = => {
const nextWidth = calculateWidth
setWidth
onResize?.
writeStoredWidth
}
<
/code>
<
/pre
>