高频更新时禁用 innerHTML +=，因其会重置事件、输入状态和焦点；应复用节点、用 key 稳定标识、控制嵌套深度、批量操作 DOM。
高频更新时为什么不能直接 innerHTML += 新内容
直接拼接字符串再赋值给 innerHTML 会清空整个容器，重置所有已绑定事件、input.value、textarea.selectionStart 和自定义 dataset 状态。哪怕只改一行文本，也会导致焦点丢失、滚动位置重置、富文本编辑器内容被抹掉。
常见错误现象：input 失去焦点后无法自动恢复；用户正在输入的表单字段突然变为空；带 data-id="123" 的按钮点击后报错 Cannot read property 'addEventListener' of null。
- 纯静态列表（无交互、无状态）可接受
innerHTML = newHtmlString，但必须确保字符串经textContent安全转义或由可信源生成 - 含用户输入、事件监听、框架组件的区域，禁止用
innerHTML增量更新 - 若必须用字符串，先用
document.createElement('template').content.innerHTML = htmlStr解析，再提取firstElementChild插入，避免执行 script 标签
documentFragment 是最小变更的前提，不是替代 diff 的方案
document.createDocumentFragment() 解决的是“插入开销”，不是“该插什么”。它不帮你判断哪几个节点要复用、哪几个要删、哪几个属性要更新——这些决策必须在 fragment 构建前完成。
容易踩的坑：把旧 DOM 节点 cloneNode(true) 后塞进 fragment，再改内容。这会复制全部事件监听器和内部状态，造成内存泄漏；且 clone 出的节点与原节点引用不同，后续无法精准比对。
立即学习“前端免费学习笔记（深入）”；
- fragment 只应装入「差异计算后确定要新增/移动的节点」，不是整棵树的副本
- 已有节点优先复用：比如列表中第 5 行数据变了，就只调用
li5.textContent = 'new value'，而不是创建新li替换 - fragment 插入后立即清空，不可缓存复用；但可缓存「变更指令」数组，如
[{op: 'update', node: li3, text: 'xxx'}, {op: 'remove', node: li7}]
key 驱动的节点复用必须稳定，否则 diff 退化为 O(n²)
列表渲染时，若没设 key 或 key 不稳定（如用 Math.random()、索引 index 当 key），Vue/React 的 diff 会放弃复用，逐个销毁重建节点。DOM 操作量暴增，高频更新下卡顿明显。
真实场景中，key 错误常表现为：拖拽排序后事件绑定错乱、输入框内容随滚动消失、checkbox 状态随机翻转。
- key 必须是稳定、唯一、可预测的标识，优先用业务 ID（如
user.id），次选哈希值（如sha256(name + email)） - 绝对不用
index作为 key，除非列表完全静态、永不增删、仅局部更新 - 无业务 ID 时，可在数据初始化阶段生成并持久化到 localStorage，避免每次刷新重算
DOM 嵌套超过 4 层就该警惕结构失控风险
每多一层嵌套，CSS 选择器匹配成本指数上升，浏览器解析 HTML 时间线性增长，滚动时强制同步布局（layout thrashing）概率大幅提高。实测显示，.a .b .c .d p 这类四层以上选择器，在长列表中触发回溯匹配，FID 常超 200ms。
问题常被掩盖：开发环境看不出卡顿，上线后用户反馈“滑动页面像幻灯片”、“点击按钮响应慢半拍”。
- 用 Chrome DevTools Elements 面板按
Ctrl+Shift+C定位节点，检查是否出现连续 4 个以上<div> 套嵌 <li>用 <code>display: flex或display: grid替代<div class="row"><div class="col"> 这类冗余包裹 <li>单个 <code><section></section>或<main></main>下子元素超过 50 个，必须拆分或改用DocumentFragment批量插入
高频动态场景下，DOM 结构稳定不是靠“写得规整”，而是靠每次变更都精确控制节点生命周期：该复用的绝不新建，该保留的状态绝不丢，该隔离的嵌套绝不放任。最易被忽略的，是把「结构语义」和「性能边界」混为一谈——
<header></header> 写得再标准，嵌套 6 层也照样卡。
