innerhtml适合整块替换且无状态依赖的场景，documentfragment适合需保留交互状态的场景，超大批量渲染必须配合虚拟滚动。
批量渲染时，innerHTML 和 createDocumentFragment 不是“谁更好”的单选题，而是“什么场景该用谁”的判断题。性能差异取决于数据量、节点复杂度、是否含表单控件、是否需保留状态，以及浏览器实际执行路径。
整块替换且无状态依赖时，innerHTML通常更快
当你要一次性清空容器、完全重绘整个列表（比如搜索结果页刷新），且列表项不含 <input>、<select></select> 或已绑定事件，innerHTML 往往是最快选择。浏览器对字符串解析和 DOM 构建做了深度原生优化，尤其在中等数据量（几百到一两千项）下，省去了 JS 层逐个创建节点的开销。
- ✅ 推荐写法：
container.innerHTML = items.map(item => `<li>${item.name}</li>`).join(''); - ❌ 避免写法：
for (const item of items) { container.innerHTML += `<li>${item.name}</li>`; }—— 每次 += 都触发一次解析+重排，性能断崖式下降 - ⚠️ 注意：所有子节点的事件监听器、焦点、输入值、
dataset全部丢失，不是 bug，是语义使然
含用户交互或需保留状态时，DocumentFragment是唯一稳妥解
只要列表里有输入框、开关按钮、自定义属性或你手动绑过事件，innerHTML 就会销毁原有节点树。此时必须用 document.createDocumentFragment() + createElement 组合，才能确保节点复用、状态留存、事件不掉线。
- ✅ 正确流程：创建 fragment → 循环
createElement并设置内容/属性/事件 →appendChild到 fragment → 最后container.appendChild(frag) - ⚠️ 关键细节：fragment 插入后自动清空，不能重复使用；多次渲染需重新
createDocumentFragment() - ? 小技巧：已有现成节点（如从模板克隆）可直接
frag.appendChild(node)，比 cloneNode 更轻——避免深拷贝事件和 dataset
超大批量（万级）渲染，两者都只是“第一关”，还得叠加虚拟滚动
无论是 innerHTML 还是 fragment，它们只解决“一次性插入”的性能问题。当列表达 10 万条，哪怕只用 fragment 插入一次，滚动时浏览器仍要 layout 所有节点，必然卡顿。此时 DOM 批量操作只是基础，真正瓶颈在布局计算。
- ✅ 必须配合虚拟滚动：只渲染可视区域 ± 缓冲区的几十个节点，其余用
transform: translateY()定位 + 占位元素撑高 - ✅ 虚拟滚动内部渲染那几十个可见项时，再用 fragment 批量插入——二者是组合关系，不是替代关系
- ❌ 别指望靠优化 innerHTML 或 fragment 解决滚动卡顿，那是方向性错误
性能临界点因浏览器而异，小量节点 createElement 反而更优
Chrome 实测显示：插入 ≤10 个简单节点（如纯文本 li）时，createElement + appendChild 比 innerHTML 快 10%~20%，因为跳过了 HTML 字符串解析阶段。这个阈值不是固定值，它随节点嵌套深度、样式复杂度、浏览器版本浮动。
- ✅ 动态生成少量结构（如弹窗内容、工具栏按钮）优先用 createElement
- ✅ 若内容来自用户输入，用
textContent+ fragment 天然防 XSS，比 innerHTML 安全且不慢 - ⚠️ 读取
offsetHeight或getComputedStyle会强制 flush layout —— 即使目标是 fragment 外的元素，也会让 fragment 的“离线性”失效
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
