虚拟列表仅优化渲染性能，不解决数据获取等其他问题；适用场景是dom节点过多导致卡顿，如超500项且含图片或复杂样式；需避免key=index、状态存组件内等常见错误。
能替代，但不是无条件替换——虚拟列表只解决渲染性能问题，不解决数据获取、状态管理、滚动行为适配等长列表的其他痛点。
什么时候该用 virtualized list 而不是普通 map 渲染？
核心判断标准是：真实 DOM 节点数是否显著影响首屏加载或滚动帧率。常见信号包括：
- 列表项超过 500 条，且每项含图片、复杂样式或内嵌组件
- 滚动时出现卡顿（Chrome DevTools 的 Performance 面板中 Layout/Recalculate Style 占比高）
-
React.memo或Vue.memo优化后仍无法缓解渲染压力 - 服务端返回的原始数据已完整，无需分页或懒加载语义
注意：virtualized list 对首次交互延迟（TTI）改善有限，它不减少 JS 解析或数据请求时间，只压缩可视区外的 DOM 构建开销。
react-window 和 react-virtual 关键差异在哪？
两者都基于“只渲染可视区域 + 占位容器高度”的思路，但设计哲学不同：
-
react-window更轻量，API 固定（FixedSizeList/VariableSizeList），适合结构规整、高度可预测的列表；不支持嵌套滚动或 sticky header -
react-virtual是底层 hook 库，不绑定 DOM，需自行组合useVirtual和真实元素；灵活性高，能对接 Canvas、WebGL 或自定义滚动容器，但需手动处理 ref、resize、scroll sync - 若项目已用
react-table或tanstack-virtual，优先沿用其内置虚拟化，避免多层抽象叠加
错误示例：VariableSizeList 中对每个 item 调用 getEstimatedItemSize 返回随机值 → 触发频繁重计算和 layout shift。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
虚拟列表里怎么保持选中/展开等本地状态？
不能依赖组件内部 useState，因为 item 组件会被反复卸载/重建。正确做法是把状态提到父级或全局 store：
- 用 Map 或对象缓存状态：
const expandedMap = useRef(new Map())，key 为 item id，避免 index 变动导致错位 - 若用 Redux/Zustand，确保 selector 按 item id 订阅，而非按索引（
state.items[2].expanded在虚拟滚动中不可靠） - 展开动画需配合
transform: scaleY()+overflow: hidden，避免触发重排；纯 height 过渡会强制重新计算所有后续 item 位置
典型坑：key={index} 用于虚拟列表项 → 滚动后状态漂移（如第 100 行展开，滚回顶部再滚下去，可能变成第 98 行展开）。
服务端分页 + 客户端虚拟列表能混用吗？
能，但必须明确分工：分页管数据边界，虚拟列表管渲染边界。常见错误配置：
- 前端虚拟列表总高度按
total * itemHeight计算，但total来自接口返回的total_count—— 若接口实际只返回第 1 页 20 条，total_count=10000，会导致滚动条过长、空白区域巨大 - 滚动到底部自动加载下一页时，直接
setData(prev => [...prev, ...newItems])→ 触发整个列表重渲染，虚拟化失效 - 正确做法：用
concat合并数据后，调用resetAfterIndex(0)（react-window）或更新useVirtual的size参数，并确保新数据插入位置与逻辑顺序一致
真正难的是滚动位置维持：用户拉到第 800 行（第 4 页末尾），加载第 5 页后，要平滑续接到第 1000 行起始位置，而不是跳回顶部或产生抖动 —— 这需要精确计算 offset 并调用 scrollTo 或 scrollToItem。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
