前端表格列拖拽为什么会抖动：用 Pointer Events 与 requestAnimationFrame 合并布局写入

后台数据表格一多，列拖拽就很容易暴露性能问题：鼠标移动时列宽一顿一顿，松手后表头和单元格还会跳一下。这个现象通常不是拖拽事件“不够快”，而是每个 pointermove 都在同步读取布局、修改宽度，浏览器被迫在一帧里反复计算。

把拖拽过程拆成“事件里只记位置，下一帧只提交一次样式”，再配合固定的最小列宽，通常就能把抖动从交互路径里拿掉；是否真的有效，要用 Performance 面板看每帧布局时间，而不是凭手感下结论。

先把列拖拽的卡顿现场量出来

先做一个 20 列、每列 200 行的表格，表头右侧放一个 6 像素的拖拽手柄。测试时不要一边开着开发者工具一边凭感觉拖，先在 Chrome DevTools 的 Performance 面板录制 3 秒：从按下手柄开始，连续拖动一列，再松手。

我会记录三个数：一次拖动产生了多少个 pointermove，主线程里超过 50ms 的长任务有几段，以及拖动最密集的 1 秒内 Layout 总耗时。下面的示例故意把表格内容做得稍重，方便看到差异。

const measure = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log('long task', entry.duration.toFixed(1), 'ms');
  }
});
measure.observe({ type: 'longtask', buffered: true });

这一步的结果不是为了制造一个漂亮的百分比，而是确定问题属于哪一层：如果事件数量很多但 Layout 几乎没有，先看事件分发；如果每次移动都伴随 Recalculate Style 和 Layout，就应该先处理读写节奏。

为什么每个 pointermove 都改宽度会抖

最容易写出的版本大致如下：回调里先用 getBoundingClientRect() 读表头当前宽度，再把指针位移加上去，最后把结果写回 style.width。问题在于，下一次回调很可能紧接着到来，而上一次写入已经让浏览器需要重新计算布局。

handle.addEventListener('pointermove', (event) => {
  const rect = headerCell.getBoundingClientRect();
  const next = rect.width + event.clientX - startX;
  headerCell.style.width = `${Math.max(96, next)}px`;
  startX = event.clientX;
});

这段代码还有一个隐性问题：它把“当前宽度”当成了状态源。指针事件如果被合并、延迟或在高刷新率下密集到达，计算会随着布局结果漂移。拖动时应该保存按下瞬间的起点宽度，宽度只由 startWidth + deltaX 得到。

把读取、计算和写入收敛到一帧

改造时保留一个 pendingX 和一个 frameId。pointermove 只更新最新横坐标；如果当前还没有待执行的帧，就预约一次 requestAnimationFrame。真正的宽度写入只发生一次，而且不再读取刚刚写过的布局。

const state = {
  dragging: false,
  startX: 0,
  startWidth: 0,
  pendingX: 0,
  frameId: 0
};

handle.addEventListener('pointerdown', (event) => {
  state.dragging = true;
  state.startX = event.clientX;
  state.startWidth = headerCell.offsetWidth;
  handle.setPointerCapture(event.pointerId);
});

handle.addEventListener('pointermove', (event) => {
  if (!state.dragging) return;
  state.pendingX = event.clientX;
  if (state.frameId) return;
  state.frameId = requestAnimationFrame(() => {
    state.frameId = 0;
    const delta = state.pendingX - state.startX;
    const width = Math.min(420, Math.max(96, state.startWidth + delta));
    headerCell.style.width = `${width}px`;
    table.style.setProperty('--active-column-width', `${width}px`);
  });
});

function stopDrag(event) {
  if (!state.dragging) return;
  state.dragging = false;
  if (state.frameId) cancelAnimationFrame(state.frameId);
  state.frameId = 0;
  handle.releasePointerCapture?.(event.pointerId);
}

handle.addEventListener('pointerup', stopDrag);
handle.addEventListener('pointercancel', stopDrag);

这里有两个值得保留的细节。第一，offsetWidth 只在 pointerdown 时读取一次；第二，使用 setPointerCapture 后，指针离开手柄仍能继续收到事件，松手时再释放捕获。拖拽的主路径不需要查询 DOM 当前宽度。

用同一组动作比较优化前后

测试动作固定下来：浏览器窗口宽度 1440 像素，20 列表格，连续拖动第 4 列 800 像素，重复 5 次。每次都从 Performance 面板里看同一段 2 秒录制，不要把第一次加载表格的成本混进去。

• 事件侧：记录 pointermove 回调总数，以及回调里是否出现 DOM 几何读取。
• 渲染侧：看 Main 线程是否出现一串紧挨着的 Recalculate Style、Layout 和 Paint。
• 结果侧：看拖动过程中有没有连续超过 16.7ms 的帧，以及松手后列宽是否回跳。

在一个普通办公本地实验里，直接读写版本常见的现象是 Layout 事件随着 pointermove 成串出现，拖动 1 秒会出现多次超过 50ms 的长任务；合帧版本把宽度写入压到每帧最多一次，长任务应明显减少。具体数字会随表格单元格内容、浏览器版本和屏幕刷新率变化，所以这里不把实验值当成线上承诺。

最小列宽、取消拖拽和兼容边界

min-width: 96px 不是装饰，它能防止列宽变成 0 后文本换行、表格重新分配宽度，进而把新的布局成本带回拖拽路径。业务上有长字段时可以把上限提高到 420px，但不要让一列无限变宽。

触控屏上要检查 pointercancel。页面滚动、系统手势或浏览器接管指针时，取消事件可能早于 pointerup 到达；如果只监听松手，表格会一直停留在拖拽状态。手柄还应设置 touch-action: none，并在取消时清除未执行的帧。

.column-resize-handle {
  width: 6px;
  cursor: col-resize;
  touch-action: none;
  user-select: none;
}

常见问题：拖拽优化后还卡，应该继续查什么

为什么用了 requestAnimationFrame 仍然会掉帧？

合帧只解决了重复写入，不会让单次渲染自动变轻。如果一帧里还要重排整张大表，继续看单帧 Layout 时长，必要时减少需要同步变宽的 DOM，或把列宽状态交给 CSS 变量。

能不能只用 pointermove 的节流函数？

可以降低回调次数，但固定的毫秒节流不一定和屏幕刷新同步。拖拽这种视觉更新更适合用 requestAnimationFrame 合并到浏览器下一帧。

为什么松手后宽度会跳回去？

通常是表头宽度改了，表格列模型或持久化状态却没有更新。结束拖拽时保存最终宽度，并让表头、col 元素和数据状态使用同一个值。

上线前的验收清单

真正上线前，我会用同一套动作再看四项：拖动期间没有连续长任务；一帧最多一次列宽写入；pointercancel 后手柄能恢复空闲；刷新页面后保存的列宽仍与表头和单元格一致。只要最后一项失败，视觉上的“顺滑”也不算完成。

这类交互的关键不是把事件回调写得更复杂，而是把布局读取移出高频路径，把写入交给帧节奏，再用数据记录确认改动确实减少了主线程工作。