直接用overflow: auto渲染几千条数据会卡顿，因DOM节点过多导致样式计算、重排重绘开销大；react-window的FixedSizeList需正确配置itemCount（真实长度）、itemSize（数字像素值），子组件必须透传style，否则白屏或错位。

为什么直接用 overflow: auto 渲染几千条数据会卡

浏览器渲染性能瓶颈不在 JS，而在 DOM 节点数量和重排重绘。哪怕只是 5000 个 <div>，DOM 树体积大、样式计算耗时、滚动时频繁触发 scroll 事件并更新视图，就会明显掉帧。虚拟滚动的核心不是“懒加载”，而是“只渲染可视区域 ± 缓冲区的节点”，其余全部用 height 占位。

react-window 的 FixedSizeList 怎么配才不白屏

常见错误是没传对 itemCount 或漏了 itemSize，导致内部计算高度为 0，列表高度塌陷，内容不可见。它要求每项高度严格一致，否则会错位或滚动跳变。

• itemCount 必须是真实数据长度，不能是 data.length || 0 这种带默认值的写法（初始为空数组时会渲染 0 项）
• itemSize 是像素值，不是字符串，写成 itemSize="72" 会失效，必须 itemSize={72}
• 子组件必须用 style 接收 style 参数并透传，否则定位错乱：

  const Row = ({ index, style }) => <div style={style}>{data[index]}</div>

原生 HTML + JS 实现最小可行虚拟滚动的关键三步

不需要框架也能做，关键是把“滚动位置 → 当前起始索引 → 渲染哪几行”这个映射链写稳，且避开 layout thrashing。

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

• 监听 scroll 事件时用 requestIdleCallback 或节流（如 lodash.throttle），避免高频触发重算
• 用 scrollTop 除以单行高度向下取整得 startIndex，再按可视区域能容纳的行数算出 endIndex，只对这个区间调用 innerHTML 或 documentFragment 批量更新
• 外层容器设固定高度 + overflow-y: auto，内部用一个空 <div> 占满总高度：style="height: ${itemHeight * itemCount}px"，保证滚动条长度正确

用 IntersectionObserver 做虚拟滚动靠谱吗

不推荐。它适合“触底加载”或“图片懒加载”，但不适合精确控制长列表渲染范围。原因有三：

立即学习“前端免费学习笔记（深入）”；

• 触发时机不可控，滚动快时会批量触发，无法对齐视口像素级边界
• 没有内置的“当前滚动偏移量”信息，要自己维护 scrollTop，反而增加复杂度
• 大量 IntersectionObserver 实例（每行一个）内存开销大，Chrome 下观察 1w 个元素会显著拖慢

真想轻量，优先用 getBoundingClientRect() + 节流判断元素是否在视口内，但要注意避免在滚动中反复读取 layout 属性。