innerHTML一用就卡因触发完整HTML解析、DOM构建和样式重计算，textContent仅更新文本节点且不触发解析；频繁更新时应优先用textContent或DocumentFragment局部更新。
为什么 innerHTML 一用就卡，但 textContent 不会？
因为 innerHTML 触发完整 HTML 解析、DOM 构建和样式重计算，而 textContent 只更新文本节点，不触发解析。在频繁更新的交互区域（比如聊天消息流、实时表格），用 innerHTML += ... 相当于反复重建子树——浏览器得删掉旧节点、新建节点、重新挂载、重排版，开销极大。
实操建议：
- 纯文本插入/更新，一律用
textContent或nodeValue - 必须插 HTML 时，避免拼接字符串后整段赋值；改用
document.createElement+appendChild局部更新 - 若需批量插入，先用
DocumentFragment缓存节点，再一次性 append 到真实 DOM
哪些元素能安全删掉而不影响功能？
常见冗余结构集中在「语义无意义」和「CSS 可替代」两类：空的 <div>、仅用于包裹的 <span>、纯样式类容器（如 class="clearfix"）、重复嵌套的 <div>（尤其 React/Vue 框架生成的 wrapper）。
判断依据不是“看着多不多”，而是“删掉后是否破坏布局或 JS 选择器”：
立即学习“前端免费学习笔记（深入）”；
- 检查 JS 中是否用
querySelector('.wrapper .item')这类强依赖层级的选择器——这类 selector 一删就失效 - 用浏览器 DevTools 的 Elements 面板右键「Break on > subtree modifications」，观察交互时哪些节点被频繁增删，它们往往是可合并或移除的目标
- 把疑似冗余节点删掉后，运行
getComputedStyle(el)对比关键样式是否变化；没变，且视觉一致，大概率可删
data- 属性塞太多，真会影响性能吗？
单个 data- 属性几乎零开销，但成百上千个（比如每行表格加 10 个 data-id、data-status、data-timestamp）会显著增加内存占用和序列化成本，尤其在调用 element.outerHTML 或做深克隆时。
更隐蔽的问题是维护成本：JS 里满屏 el.dataset.userId、el.dataset.userRole，一旦后端字段名变更，前端全要改。
- 优先用 JS 对象缓存业务数据，DOM 只留最必要标识，例如只留
data-id="123"，其余通过 Map 查表：userDataMap.get(el.dataset.id) - 避免用
data-存复杂结构（如 JSON 字符串），这会让解析逻辑散落在各处，也增加 HTML 体积 - 用
MutationObserver监听data-变更？别——直接改 JS 状态再同步 UI 更可控
自定义元素（Custom Elements）让 DOM 更精简，还是更臃肿？
用得糙，就是套壳 div + 大量 shadowRoot 开销；用得准，才能真正收敛结构。关键不在“用了没”，而在“是否替代了原本的嵌套 wrapper”。
比如一个带图标、标题、开关的控件，传统写法常是 4–5 层 <div> 嵌套；封装为 <user-card> 后，模板内仍用一堆 <div>，那只是换了个名字的臃肿。
- 自定义元素的
template内部也要遵循精简原则：能用伪元素实现的 icon，不用额外<i>标签；能用 CSS Grid 排列的，不靠三层<div>套娃 - 慎用
shadow DOM：它隔离样式是优点，但调试困难、SSR 支持弱、SEO 友好性存疑；内部结构简单、无样式冲突风险的组件，用 light DOM 更轻量 - 别为了封装而封装——如果一个组件只在一处使用、逻辑不到 10 行，硬抽成自定义元素反而增加加载和解析负担
DOM 树精简不是删标签比赛，核心是让每个节点都有不可替代的存在理由。最易被忽略的是：JS 选择器越具体，HTML 就越不敢动；反过来，HTML 越松散，JS 就越难维护。两者得一起收口。
