直接渲染几千行会卡死浏览器，因dom节点过多导致重排重绘开销剧增；应采用虚拟滚动仅渲染可视区域±缓冲区，配合固定行高、节流scroll、占位高度等方案优化。

为什么直接渲染几千行 <div> 会卡死<p>浏览器渲染长列表时，DOM 节点一多，重排（reflow）和重绘（repaint）开销就指数级上升。哪怕只是 5000 个 <code><div>，首次挂载也可能卡顿 1–2 秒，滚动时掉帧严重——这不是 JS 慢，是 Layout + Paint 瓶颈。<p>关键不是“删代码”，而是绕过浏览器对“不可见区域”的无谓计算。真实场景中，用户同一时间最多看到 20 行，那其余 4980 行就不该存在 DOM 中。</p> <p>实操建议：</p> <ul> <li>禁用 <code>display: none 或 visibility: hidden 隐藏行：它们仍参与布局计算，毫无优化效果

避免用 transform: translateY() 把所有行一次性位移：DOM 还在，内存和样式计算照旧

优先考虑「只渲染可视区域 ± 缓冲区」的方案，缓冲区一般设为 3–5 行，兼顾滚动平滑与内存占用

用 IntersectionObserver 做懒加载渲染是否可行

可以，但不推荐用于高频滚动场景。它适合“触底加载”或“分页式展开”，比如无限下拉；但对快速拖拽滚动的长列表，IntersectionObserver 回调延迟明显，容易出现白屏或闪动。

真正有效的做法是监听 scroll 事件 + 虚拟滚动（virtual scrolling）：手动计算当前滚动位置对应的起始索引，再用 slice() 截取数据子集，仅渲染这部分。

注意点：

• 必须节流 scroll 事件（如用 requestAnimationFrame），否则滚动中频繁触发重渲染
• 容器需固定高度、overflow-y: auto，且内部用一个高占位 <div> 模拟总高度（例如 <code>style="height: calc(24px * 5000)"）
• 每一项必须有固定行高（或预估高度），否则无法准确计算可视范围

React/Vue 项目里怎么接虚拟滚动

别手写。主流框架都有成熟方案，重点是选对库+配对参数。


Html2md
使用 Readability + Turndown 将 HTML 页面转换为干净的、Agent 友好的 Markdown。去除导航栏、广告、页脚、Cookie 横幅、社交按钮等干扰元素。支持 URL...
下载

React 推荐 react-window（轻量）或 react-virtualized（功能全）：

• 用 FixedSizeList 替代 map() 渲染，传入 itemSize 和 height
• 不要把整个数据数组传给组件，而是传 itemData（引用不变）+ itemKey（稳定 key）
• 若行高不一致，改用 VariableSizeList，但需提供 getItemSize 函数，性能略降

Vue 推荐 vue-virtual-scroller 或组合式 API + useVirtualList（如 @vueuse/core 提供）：

• 避免在 v-for 外层套 v-show 或 v-if 控制显隐——这等于没做虚拟化
• 确保 item 组件是函数式/无状态的，减少响应式开销
• 开启 useIsScrolling 属性，在滚动中临时降级内容（比如隐藏图片、简化图标）

服务端渲染（SSR）或静态生成（SSG）时怎么处理

虚拟滚动依赖客户端滚动位置，SSR/SSG 无法直接运行。硬要首屏渲染全部数据，又回到卡顿原点。

折中解法是「分层渲染」：

• 服务端只渲染首屏可见区域（比如前 20 行）+ 一个占位 <div> 表示剩余高度<li>客户端 hydration 后立即接管，用虚拟滚动逻辑补全后续内容</li> <li>配合 <code>data-hydrate="false" 或 client:only（Svelte/Nuxt）跳过服务端虚拟化逻辑

注意：若首屏内容本身就要搜索/筛选，得在服务端预计算过滤后结果再截取，否则客户端 hydration 后数据对不上。

最易被忽略的一点：滚动容器的 scrollTop 在 SSR hydrate 后会被重置为 0，必须在 useEffect / onMounted 中手动恢复，否则用户刷新页面会跳回顶部。