DOM树深度超6层会触发浏览器隐式分块渲染，导致重排耗时翻倍、合成层碎片化；应使用语义标签、CSS containment及template优化结构与渲染性能。
DOM树深度超6层会触发浏览器分块渲染降级
浏览器不会主动“分块渲染”，但当DOM树过深（比如7层以上嵌套），布局引擎（如Blink的LayoutTree）在构建渲染树时会隐式拆分计算单元，把原本可合并的样式继承链、几何计算范围强行切片——结果是同一视觉区块被当成多个独立渲染片段处理，导致重排耗时翻倍、合成层碎片化。
常见错误现象：document.querySelector('.content').offsetTop返回0或异常值；Chrome DevTools 的“Layers”面板显示大量LayoutObject碎片；滚动时出现局部闪烁。
- 用
document.body.querySelectorAll('*')统计节点总数，再配合node.depth（右键Elements中节点→“Show DOM properties”）确认是否超6层 - 优先用
<main><section><article>替代<div class="wrap"><div class="inner"><div class="box">这类三层纯容器 - 避免在
<table>内再套<div>做布局——表格本身已是强约束盒模型，额外嵌套会强制布局引擎重复解析行列结构
语义标签缺失会让CSS containment失效
contain: layout style paint这类现代CSS隔离机制，依赖浏览器对DOM语义边界的准确识别。如果用<div class="card">代替<article class="card">，布局引擎无法确认该节点是否构成独立内容单元，contain可能被忽略或降级为contain: size，失去样式与布局隔离能力。
使用场景：卡片列表、模态框、广告位等需要局部重绘控制的区域。
立即学习“前端免费学习笔记（深入）”；
- 检查
getComputedStyle(el).contain是否返回预期值，而非none -
<article>必须带标题（<h2>–<h6>），否则浏览器视同<div>，contain不生效 - SSR输出中确保语义标签已存在，不要靠JS运行后动态替换
<div>——服务端没语义，客户端补也晚了
<template>绕过HTML解析阶段直接注入DOM
<template>内容不参与初始HTML解析流程，也不触发JS执行或样式计算。当你调用document.importNode(template.content, true)插入时，浏览器跳过词法分析（Tokenizer）和树构建（Tree Construction）两个主线程密集型阶段，只做内存克隆+挂载，本质是把“解析开销”从渲染流水线里摘出去。
性能影响：相比el.innerHTML = htmlStr，克隆template.content可减少30%~50%主线程阻塞时间（实测Chrome 128下100个节点插入场景）。
-
template.content是DocumentFragment，不能直接querySelector，需先el.appendChild(clone)再查子节点 - 模板内
<script>和<style>会被忽略，事件监听必须手动绑定（clone.addEventListener） - 不要在
<template>里写id属性——克隆后ID重复，后续document.getElementById行为不可控
嵌套<table>强制触发整行回流
表格布局的table-layout: auto默认行为是扫描全部<td>内容宽度后再确定列宽。若嵌套多层（如<table><tr><td><table>...），每层都会触发独立的“全行扫描→列宽推导→重排”循环，JS执行完后积压的回流任务会集中爆发，用户感知就是点击后界面卡顿半秒才响应。
容易踩的坑：CMS生成的邮件模板、后台报表组件常滥用嵌套表格实现“灵活布局”，实际却严重拖慢渲染。
- 用
table-layout: fixed+<col>显式定义列宽，让浏览器跳过内容扫描 - 超过2层嵌套的
<table>建议重构为display: grid或display: flex——它们不依赖行级上下文，布局计算更扁平 - Chrome DevTools → Rendering → 勾选“Paint flashing”，滚动时若表格区域高频闪烁，说明重绘压力过大
<div>，只在意你有没有给它清晰的语义边界和计算锚点。 
