上周排查一个后台系统的性能问题：当用户勾选表格50列+2000行数据时，页面直接卡死10秒。你以为这是个简单的「大数据渲染」问题？用分页或虚拟列表就能解决？Too young.
现象：你以为的优化可能完全无效
那个表格使用了Ant Design的Table组件，默认开启了rowSelection和rowExpand功能。最初的优化尝试是这样的：
// 错误示范：简单加个memo
const MemoRow = React.memo(({ record }) => (
<tr>
<td>{record.id}</td>
{/* 48个其他字段... */}
</tr>
));
function TableDemo() {
return (
<Table
components={{ body: { row: MemoRow } }}
// ...其他配置
/>
);
}
结果：渲染耗时从10秒降到了……9.8秒。为什么？因为真正的性能黑洞根本不在这里。
根因：被忽视的选择状态扩散
打开React DevTools的性能分析器，发现95%的时间消耗在「计算选中状态」上。根源在于：
- 不可变数据集的重复计算：每次勾选时，父组件都会生成全新的
dataSource数组（即使只有一行数据变化） - AntD的内部实现：
rowSelection会深度比较每个record对象是否在selectedRowKeys中 - 引用断裂陷阱：由于
dataSource全部重建，所有行都触发重新渲染
// 典型错误：每次setState都创建全新数组
const [data, setData] = useState(originData);
const handleSelect = (record) => {
setData(prev => prev.map(item =>
item.id === record.id ? { ...item, selected: !item.selected } : item
));
};
正确解法：双重缓存策略
- 第一层缓存*：用
useMemo冻结未变化的数据引用
const stableData = useMemo(() =>
originData.map(item => ({ ...item })),
[originData /* 只在源头数据变化时重建 */]);
- 第二层缓存*：分离选中状态与数据本体
const [selection, setSelection] = useState(new Set());
// 选中逻辑变成O(1)复杂度
const handleSelect = (id) => {
setSelection(prev => {
const next = new Set(prev);
next.has(id) ? next.delete(id) : next.add(id);
return next;
});
};
// 渲染时合并状态
<Table
dataSource={stableData.map(item => ({
...item,
_selected: selection.has(item.id)
}))}
/>
实测结果：2000行数据的选择操作从10秒→200ms，性能提升98%。
避坑清单：处理复杂列表必知的5个要点
- 不要滥用memo：如果父组件每次都传递新引用，子组件缓存会完全失效
- 状态分离原则：高频变化的状态（如选中态）应与低频变化的数据（如表格内容）隔离
- 警惕第三方组件的隐藏开销：AntD Table的
expandedRowRender会在每次渲染时递归执行 - 批量更新策略：对于超长列表，用
unstable_batchedUpdates合并多次setState - 不可变数据的代价：
arr.map()产生的内存压力可能超过直接修改（需实测权衡）
更深层的思考
- 虚拟列表真的是银弹吗？* 在笔者测试中，当单元格内有复杂表单控件时，react-window的滚动会出现输入框失焦问题。这时候你可能反而需要：
// 粗暴但有效的方案：控制渲染窗口的余量
<List
height={500}
itemCount={1000}
itemSize={35}
overscanCount={10} // 多渲染20行作为缓冲
/>
你在处理超长列表时还踩过哪些坑？欢迎分享你的实战解法。
