直接循环生成几万条<li>会卡死浏览器，因渲染是边解析DOM边布局、样式计算、重排重绘，而非生成完再画；几万个节点一次性插入会压垮主线程渲染管线。
为什么直接循环生成几万条 <li> 会卡死
浏览器渲染不是“生成完再画”，而是边解析 DOM 边布局、边样式计算、边重排重绘。几万个 <li> 节点一塞进 innerHTML 或 appendChild，主线程立刻被 DOM 构建 + 样式计算 + layout 占满，页面冻结几秒甚至崩溃。这不是 JS 慢，是渲染管线过载。
实操建议：
立即学习“前端免费学习笔记（深入）”；
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 别用
for (let i = 0; i —— 每次 <code>appendChild都可能触发重排 - 改用
DocumentFragment批量插入：const frag = document.createDocumentFragment();<br>for (let i = 0; i < 10000; i++) {<br> const li = document.createElement('li');<br> li.textContent = i;<br> frag.appendChild(li);<br>}<br>ul.appendChild(frag); // 仅一次真实 DOM 插入 - 更进一步：用
innerHTML字符串拼接（注意 XSS）比逐个创建元素快，但超过 ~5000 条时字符串构建本身也成瓶颈
滚动时只渲染可视区域：用 IntersectionObserver 还是 getBoundingClientRect()
IntersectionObserver 是现代方案，轻量、异步、不阻塞主线程；getBoundingClientRect() 需手动绑定 scroll 事件，容易因频繁触发导致掉帧。但前者兼容性差（IE 不支持），后者在老项目里仍是刚需。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 新项目优先用
IntersectionObserver监听列表项是否进入视口，动态append/remove节点 - 若需兼容 IE，用
getBoundingClientRect()+throttle（节流），且只对「正在滚动中」的元素做判断，避免每次 scroll 都遍历全部项 - 别忘了给容器设固定高度和
overflow-y: auto，否则无法形成滚动上下文，视口判断失效
虚拟滚动（virtualized list）为什么不能只靠 CSS transform 位移
纯 CSS 位移（如用 transform: translateY(2000px) 把第 2000 行“推”到可视区）看似省 DOM，但实际所有数据仍得存在内存里，滚动越远，JS 对象越多，GC 压力大；而且无法响应用户点击某一行的真实索引（你看到的是第 2000 行，但 DOM 节点可能是第 0 个 <li>）。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 虚拟滚动必须配合「数据映射」：维护一个
startIndex和visibleCount，每次滚动后重新计算并更新innerHTML或重用节点 - 复用节点比新建更快：用
Array.from({length: visibleCount})渲染固定数量的<li>，再用dataset.index绑定真实数据下标 - 滚动容器需预留「缓冲区」（比如多渲染前后各 5 行），避免快速滑动时白屏
requestIdleCallback 适合分批渲染，但别指望它解决根本问题
它只是把任务塞进浏览器空闲时段执行，不改变总耗时。如果单次渲染 1000 条仍要 80ms，分 10 批每批 100 条，还是占满 10 个空闲窗口——用户照样感知卡顿，尤其低端机上空闲时间少，可能拖得更久。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 仅用于「非关键路径」的补全，比如加载完首屏后，用
requestIdleCallback异步补上剩余 20% 的次要项 - 不要用它替代虚拟滚动或分页；它不是渲染优化的银弹，而是锦上添花
- 记得检测 API 是否存在（Safari 旧版不支持），降级为
setTimeout(..., 0)
