innerhtml一用就卡因触发完整html解析、dom构建和样式重计算，textcontent仅更新文本节点且不触发解析；频繁更新时应优先用textcontent或documentfragment局部更新。
为什么 innerHTML 一用就卡，但 textContent 不会？
因为 innerHTML 触发完整 HTML 解析、DOM 构建和样式重计算，而 textContent 只更新文本节点，不触发解析。在频繁更新的交互区域（比如聊天消息流、实时表格），用 innerHTML += ... 相当于反复重建子树——浏览器得删掉旧节点、新建节点、重新挂载、重排版，开销极大。
实操建议：
- 纯文本插入/更新，一律用
textContent或nodeValue - 必须插 HTML 时，避免拼接字符串后整段赋值；改用
document.createElement+appendChild局部更新 - 若需批量插入，先用
DocumentFragment缓存节点，再一次性 append 到真实 DOM
哪些元素能安全删掉而不影响功能？
常见冗余结构集中在「语义无意义」和「CSS 可替代」两类：空的 <div>、仅用于包裹的 <code><span></span>、纯样式类容器（如 class="clearfix"）、重复嵌套的 <div>（尤其 React/Vue 框架生成的 wrapper）。
<p>判断依据不是“看着多不多”，而是“删掉后是否破坏布局或 JS 选择器”：</p>
<ul>
<li>检查 JS 中是否用 <code>querySelector('.wrapper .item') 这类强依赖层级的选择器——这类 selector 一删就失效
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> 嵌套；封装为 <code><user-card></user-card> 后，模板内仍用一堆 <div>，那只是换了个名字的臃肿。
<ul><li>自定义元素的 <code>template 内部也要遵循精简原则：能用伪元素实现的 icon，不用额外 <i></i> 标签；能用 CSS Grid 排列的，不靠三层 <div> 套娃
<li>慎用 <code>shadow DOM：它隔离样式是优点，但调试困难、SSR 支持弱、SEO 友好性存疑；内部结构简单、无样式冲突风险的组件，用 light DOM 更轻量
DOM 树精简不是删标签比赛，核心是让每个节点都有不可替代的存在理由。最易被忽略的是：JS 选择器越具体，HTML 就越不敢动；反过来，HTML 越松散，JS 就越难维护。两者得一起收口。
