真实渲染树只包含参与视觉渲染的节点且绑定计算样式；它过滤掉注释、display: none 元素、head 标签、无 content 的伪元素等，而 visibility: hidden 元素仍保留在渲染树中。
真实渲染树（Render Tree）不是 DOM 树的副本，也不是 CSSOM 的简单叠加——它只包含**参与视觉渲染的节点**，且每个节点都已绑定计算后的样式。想看它？浏览器 DevTools 不直接暴露完整结构，但可通过 getComputedStyle 和 offsetParent 等 API 间接验证。
为什么 document.body.children ≠ 渲染树节点？
DOM 树里存在大量不渲染的节点：注释、display: none 元素、 内容、伪元素（除非被显式触发）、<script></script> 和 <meta> 标签本身。这些在构建渲染树时被直接过滤掉。
-
display: none的元素不会进入渲染树，哪怕它有子元素；而visibility: hidden的元素仍在渲染树中，只是绘制阶段跳过像素输出 -
<title></title>、<base>、<style></style>（标签节点本身）不生成渲染器（renderer），但<style></style>的内容会影响其他节点的样式计算 - 伪元素如
::before只有在 CSS 中声明了content属性才会创建对应渲染器，否则无节点
getComputedStyle 返回值能反映渲染树状态吗？
不能直接等同，但它是验证节点是否“已参与样式计算”的最可靠手段。对一个节点调用 getComputedStyle(el)，若返回空对象或报错（如 el 为 null 或未附加到文档），说明它大概率不在渲染树中。
- 注意：
getComputedStyle对display: none元素仍返回有效样式对象（含默认值），但它实际没被插入渲染树 —— 所以需结合el.offsetParent === null判断是否参与布局 -
el.offsetParent为null通常表示该元素不参与布局（常见于display: none、position: fixed且父级无定位上下文等情况） - 动态插入的节点，必须已 attach 到 DOM 且完成一次样式计算周期（即至少经历一次 layout 触发），
getComputedStyle才稳定可读
Chrome DevTools 中哪些面板泄露了渲染树线索？
没有“渲染树”专用面板，但三个地方能交叉印证：
立即学习“前端免费学习笔记（深入）”；
- Elements 面板：右键节点 → “Show layout editor”，若显示尺寸/边距/盒模型，则该节点已生成 renderer；灰色禁用状态往往意味着未渲染
- Rendering 面板（需开启）→ 勾选 “Paint flashing”，只有真正参与绘制的区域会高亮；未高亮区域即使 DOM 存在，也未进入最终绘制流程
- Layers 面板：只显示被提升为独立图层的节点（如含 transform、opacity 的元素），它们是渲染树的子集，但层级划分发生在渲染树之后，不能反推全部结构
真正难的是跨 frame、SVG 内嵌、CSS containment 等边界场景——display: contents 会让父节点消失，子节点“冒泡”进父级渲染上下文；contain: layout paint 则人为切断渲染树继承链。这些细节不写死在 API 里，只体现在引擎内部构造逻辑中。
