手把手实现一个灵活可复用的右键菜单组件

优化前：卡得不行

上周我们项目里有个右键菜单功能，用户反馈“点一下右键要等半秒才弹出来”，我一开始还不信，本地开发环境跑得挺顺的。结果一上测试环境，好家伙，点右键后整个页面卡住，鼠标转圈，连滚动都卡顿。打开控制台一看，Performance 面板里满屏的紫色长条——全是强制重排（forced reflow）和重绘（repaint）。

这菜单本来是用 React 写的，每次右键触发就重新 render 一个完整组件，包含十几项动态生成的菜单项，每项还要查权限、拼 URL、加图标。更糟的是，菜单 DOM 是直接挂载在 body 下的，但每次 show 的时候都重新创建 + 挂载，hide 的时候又 remove。频繁操作 DOM，加上 React reconciler 的开销，性能直接拉胯。

找到病灶了！

我先用 Chrome DevTools 的 Performance 录了一次右键操作。放大时间线一看，问题很明显：

• 每次右键触发，有 300ms+ 的 Scripting 时间，主要花在 React 组件实例化和 props 计算上
• 紧接着是 150ms 的 Layout（重排），因为新 DOM 被插入到 body，浏览器要重新计算所有元素位置
• 最后还有 80ms 的 Paint，虽然不多，但叠加起来已经快 500ms 了

再用 React DevTools 的 Profiler 看，发现菜单组件每次渲染都触发了大量子组件的重新 mount/unmount。原来是因为我们把菜单写成“每次显示就新建，隐藏就销毁”的模式，完全没复用。

折腾了半天发现，核心问题就两个：频繁创建/销毁 DOM 和 每次渲染都做全量计算。

核心优化方案：复用 + 懒计算

我试了几种方案：

• 方案一：用 CSS display 控制显隐，不销毁组件。但菜单内容每次都要重新计算，还是卡
• 方案二：把菜单数据缓存起来，但权限和 URL 拼接逻辑太复杂，缓存容易失效
• 方案三（最终采用）：只创建一次 DOM，显隐用 visibility + transform，菜单项按需生成

重点来了：菜单容器只初始化一次，挂载后就不再移除。右键时只更新位置和内容，但内容也不是全量更新——而是根据当前上下文（比如选中的文件、当前页面状态）动态生成菜单项数组，然后 diff 一下，只更新变化的部分。

另外，把耗时的权限判断和 URL 拼接移到“真正 hover 到某一项时”才执行，而不是在菜单弹出时全量跑一遍。用户一般只点一项，其他项根本不用算。

下面是优化前后的关键代码对比：

// 优化前：每次右键都重新创建整个菜单
function handleContextMenu(e) {
  e.preventDefault();
  const menuItems = generateMenuItems(currentContext); // 全量生成，包含权限判断、URL 拼接等
  ReactDOM.render(
    <ContextMenu items={menuItems} />,
    document.getElementById('context-menu-root')
  );
}

// 优化后：复用容器，懒计算菜单项
let menuContainer = null;
let cachedItems = [];

function initMenu() {
  if (!menuContainer) {
    menuContainer = document.createElement('div');
    menuContainer.id = 'context-menu';
    menuContainer.style.visibility = 'hidden';
    menuContainer.style.position = 'fixed';
    document.body.appendChild(menuContainer);
    
    // 只 render 一次，后续只更新 props
    ReactDOM.render(<ContextMenu items={[]} />, menuContainer);
  }
}

function handleContextMenu(e) {
  e.preventDefault();
  initMenu();
  
  // 仅生成基础结构（不含权限/URL），用于快速展示
  const basicItems = getBasicMenuItems(currentContext);
  
  // 快速更新位置和基础项
  menuContainer.style.left = ${e.pageX}px;
  menuContainer.style.top = ${e.pageY}px;
  menuContainer.style.visibility = 'visible';
  
  // 异步懒加载完整项（hover 时才用）
  setTimeout(() => {
    const fullItems = basicItems.map(item => ({
      ...item,
      // 权限和 URL 拼接延迟到需要时
      getFullData: () => generateFullItemData(item)
    }));
    cachedItems = fullItems;
    // 这里可以触发 React 更新，但只更新必要字段
    updateMenuItems(fullItems);
  }, 0);
}

这里注意我踩过好几次坑：一开始用 display: none/block 切换，但会导致每次显示都触发重排。后来改用 visibility: hidden/visible + transform: translate，配合 will-change: transform，让浏览器提前分层，避免 layout。

#context-menu {
  position: fixed;
  visibility: hidden;
  transform: translate(0, 0);
  will-change: transform;
  z-index: 9999;
}

性能数据对比

优化前后，我在中低端笔记本（i5-8250U + 8GB RAM）上测了 10 次右键操作，取平均值：

• 首次弹出时间：从 480ms 降到 75ms（快了 6 倍多）
• 后续弹出时间：从 320ms 降到 40ms（因为容器已存在，只需更新位置）
• 主线程阻塞时间：从 450ms 降到 60ms，页面滚动不再卡顿

最关键的是，用户感知上“点右键立刻弹出”，再也不用等那半秒的焦虑了。

当然，这个方案不是完美的。比如菜单项特别多（>50 项）时，首次生成 basicItems 还是有几十毫秒延迟。但实际业务中，菜单项一般不超过 10 个，所以影响不大。如果真遇到超大菜单，可以考虑虚拟滚动，不过那是另一个故事了。

踩坑提醒：这三点一定注意

• 别在菜单里放复杂动画：我一开始加了个淡入效果，结果 animation 触发额外 composite，反而更卡。后来直接去掉，用纯 transform 位移，流畅度反而更高
• 记得防抖：用户可能快速连续右键，要加个简单防抖，避免多次触发位置更新
• 卸载时清理：虽然菜单容器不销毁，但页面 unload 时要手动 remove，否则内存泄漏。这点我差点忘了，直到内存监控报警

以上是我对右键菜单性能优化的实战总结。核心就两点：复用 DOM 容器 + 懒计算菜单内容。这个技巧的拓展用法还有很多，比如 tooltip、dropdown 也可以这么搞。后续会继续分享这类博客。

有更优的实现方式欢迎评论区交流——比如你们是怎么处理超大菜单的？或者有没有用 Web Worker 做菜单项预计算的？