React渲染近万条数据表格时脚本执行耗时过长如何解决？

这个坑我前年做后台审计日志模块的时候实打实踩过，当时要渲染9800多条带操作日志详情、状态标签的表格，Chrome性能面板拉出来全是紫色的长任务，脚本执行阶段卡到4.2s，点个筛选按钮要等3秒才有反应，前后优化了两版把耗时压到80ms左右，亲测有效的方案按落地优先级排：

• 第一优先级直接上虚拟滚动，投入产出比最高，别一上来就硬加分页，很多业务场景就是要求无分页连续滚动查数据的。不推荐自己手写虚拟滚动逻辑，边缘情况太多容易出滚动错位、白屏的bug：React 18+项目直接用@tanstack/react-virtual，和antd、arco这类主流组件库的Table适配成本极低，核心逻辑就是只渲染可视区域+上下缓冲区的几十条DOM，剩下的区域用空容器撑高度，1w条数据实际挂载到页面上的DOM节点也就50个上下，脚本执行时间直接能压到100ms以内。
  虚拟滚动落地注意两个高频坑：
  • 行高尽量固定，如果确实要做自适应行高，一定要开启动态行高测量参数，别硬写死固定行高导致滚动位置错位
  • 单元格里的自定义渲染组件一律用React.memo做缓存，避免滚动时触发全量单元格重渲染
• 暂时上不了虚拟滚动的话，先做渲染剪枝把无效开销砍了：
  • 单元格里非首屏必须的元素全部懒加载：比如hover才显示的操作按钮、超长文本的tooltip、复制图标这些，别初次渲染的时候全挂载上去
  • 所有数据格式化逻辑（日期转格式、金额加千分位、状态码转文案标签）全部提前到拿到接口响应的时候预处理完存起来，渲染阶段直接读现成的值，别每次render都遍历全量数据跑转换逻辑
  • 别拿开发环境的性能数据当优化依据：React严格模式的双渲染、DevTools的组件检测逻辑会把渲染耗时放大2-3倍，先打生产包测真实耗时再动手优化，白做无用功的情况我见太多了
• 大表格别直接用组件库自带的全选、批量选择逻辑，这类逻辑默认会遍历全量数据计算选中态，1w条数据很容易跑出几百毫秒的长任务，自己维护一个存选中项ID的Set结构单独算选中态，性能会高非常多。
• React 18项目可以把表格的更新渲染逻辑包在startTransition里，标记为非紧急更新，不会阻塞输入、点击这类高优先级的用户交互，哪怕渲染需要一点时间，用户也不会感觉到页面完全卡死。

别浪费时间试网上说的requestIdleCallback分片渲染方案，我最开始就踩过这个坑，折腾一下午确实把初次渲染的长任务拆碎了，但是本质上还是要把1w条数据对应的几万个DOM全挂到页面上，光DOM重排重绘的开销就足够让页面滚动掉帧，属于治标不治本。

Chrome浏览器性能检测截图

内容的提问来源于stack exchange，提问作者Jonathan