共计 3327 个字符，预计需要花费 9 分钟才能阅读完成。
背景痛点：为什么传统标注页面会卡顿？
在 BERT 项目的实体标注任务中，我们经常遇到需要标注数千条文本实体的情况。传统的实现方式简单粗暴——一次性渲染所有 DOM 节点，这会导致几个典型问题：
- DOM 节点爆炸 ：每条文本平均生成 15-20 个 DOM 节点，1000 条数据就意味着 15000+ 节点，直接拖慢渲染性能
- 主线程阻塞 ：标注数据的预处理（如分词、实体匹配）占用主线程，导致界面冻结
- 内存泄漏 ：频繁操作 DOM 容易引发内存泄漏，随着标注时间延长越来越卡
通过 Chrome Performance 分析可以看到，传统方案中 Scripting 时间占比超过 70%，其中 DOM 操作消耗了大部分资源。
技术选型：虚拟滚动方案对比
解决长列表性能问题，业界主要有两个成熟的 React 方案：
- react-window（推荐）
- 优点：轻量级（仅 5KB）、专为简单列表优化、API 简洁
- 缺点：不支持动态高度（需要额外配置）
- react-virtualized
- 优点：功能全面（支持 Grid、Masonry 等布局）
- 缺点：体积较大（>100KB）、学习曲线陡峭
考虑到标注页面主要是线性文本列表，我们选择 react-window 作为基础方案。实测显示，在 1000 条数据场景下：
| 方案 | 首次渲染时间 | FPS | 内存占用 |
|----------------|-------------|------|---------|
| 传统方案 | 4200ms | 12 | 280MB |
| react-window | 380ms | 58 | 32MB |核心实现方案
1. Web Worker 数据预处理
将耗时的数据预处理移出主线程：
// worker.ts
self.onmessage = (e) => {const { rawText} = e.data;
// 模拟 BERT 分词处理
const tokens = heavyTokenize(rawText);
postMessage({tokens});
};
// 主线程调用
const worker = new Worker('worker.js');
const processData = async (texts: string[]) => {
const results = await Promise.all(
texts.map(text =>
new Promise(resolve => {worker.onmessage = (e) => resolve(e.data);
worker.postMessage({rawText: text});
})
)
);
return results;
};2. IndexedDB 本地缓存
实现标注进度本地持久化：
// useCache.ts
const useCache = (projectId: string) => {const [cache, setCache] = useState<Record<string, Entity[]>>({});
useEffect(() => {const initDB = async () => {
const db = await openDB('AnnotationDB', 1, {upgrade(db) {db.createObjectStore('projects');
}
});
const saved = await db.get('projects', projectId);
if (saved) setCache(saved);
};
initDB();}, [projectId]);
const updateCache = useCallback(async (id: string, entities: Entity[]) => {const newCache = { ...cache, [id]: entities };
setCache(newCache);
const db = await openDB('AnnotationDB');
await db.put('projects', newCache, projectId);
}, [cache, projectId]);
return {cache, updateCache};
};3. 标注结果差分提交
通过对比算法减少网络请求：
const diffAnnotations = (oldEntities: Entity[],
newEntities: Entity[]) => {const changes: Change[] = [];
// 检测新增 / 修改
newEntities.forEach(newEnt => {const oldEnt = oldEntities.find(e => e.id === newEnt.id);
if (!oldEnt || !deepEqual(oldEnt, newEnt)) {changes.push({ type: 'UPDATE', entity: newEnt});
}
});
// 检测删除
oldEntities.forEach(oldEnt => {if (!newEntities.some(e => e.id === oldEnt.id)) {changes.push({ type: 'DELETE', id: oldEnt.id});
}
});
return changes;
};性能指标对比
优化前后的 Lighthouse 报告关键数据：
| 指标 | 优化前 | 优化后 | 提升 |
|----------------|-------|-------|-------|
| 首次内容渲染 | 4.2s | 0.8s | 81% |
| 交互准备时间 | 5.1s | 1.2s | 76% |
| 内存使用量 | 280MB | 45MB | 84% |
| FPS 稳定性 | 12-60 | 58-60 | 400% |避坑指南
Web Worker 通信序列化
注意：postMessage 会进行结构化克隆，大对象传输很耗时。解决方案：
// 错误做法：传输完整数据集
worker.postMessage({hugeArray});
// 正确做法：分片传输
const CHUNK_SIZE = 100;
for (let i = 0; i < hugeArray.length; i += CHUNK_SIZE) {
worker.postMessage({chunk: hugeArray.slice(i, i + CHUNK_SIZE),
index: i
});
}虚拟滚动动态高度
react-window 默认需要指定 itemSize，处理不等高文本的方案：
const [heights, setHeights] = useState<number[]>([]);
const getItemSize = (index: number) => {return heights[index] || 60; // 默认高度
};
const measureHeight = (index: number, height: number) => {
setHeights(prev => {const newHeights = [...prev];
newHeights[index] = height;
return newHeights;
});
};
// 在渲染的 Item 组件内
useLayoutEffect(() => {const height = ref.current?.getBoundingClientRect().height || 0;
measureHeight(index, height);
}, [content]);延伸思考：方案迁移到其他 NLP 任务
这套架构可以复用到：
- 关系抽取 ：将实体标注改为关系连线，Web Worker 处理图布局计算
- 文本分类 ：用同样的缓存机制保存分类标签
- 序列标注 ：调整虚拟滚动配置以适应多行文本
关键调整点：
- 修改 Web Worker 中的数据处理逻辑
- 扩展 IndexedDB 的存储结构
- 根据标注类型调整差分算法
总结
通过组合虚拟滚动、Web Worker 和本地缓存三大技术，我们实现了：
- 标注页面加载时间从 4s+ 降到 1s 内
- 内存占用减少 84%
- 标注操作流畅度提升 4 倍
这套方案已在我们的 BERT 项目中稳定运行 6 个月，支持了超过 20 万条数据的标注任务。希望这些实践对面临类似问题的团队有所启发。
最终的架构图如下（简化版）：
graph TD
A[原始文本] --> B(Web Worker 预处理)
B --> C[虚拟滚动列表]
C --> D{用户标注}
D --> E[差分提交]
E --> F[后端 API]
D --> G[IndexedDB 缓存]正文完
