CSS Grid通过单层DOM容器实现多维布局，使浏览器仅需一次布局计算，避免深层嵌套引发的递归重排；它用grid-area、grid-template-areas等直接定位直系子元素，替代传统方案中为对齐或分区而添加的冗余wrapper，显著降低DOM深度与渲染开销。
因为 CSS Grid 允许用单层 DOM 容器完成多维布局，浏览器只需一次布局计算，避免深层嵌套触发的递归重排。
Grid 如何减少 HTML 层级
传统方案（如 float + inline-block 或多层 flex）常需为每个逻辑区域添加 wrapper 元素：比如一个仪表盘要分 header / sidebar / main / footer，可能写出 4 层嵌套 div；而 Grid 只需一个 .layout 容器，内部直系子元素通过 grid-area 或 grid-column/grid-row 定位。
常见错误现象：div 套 div 套 div，只为让某个按钮“贴右上角”，结果 DOM 深度达 5 级，CSS 却只用了 position: absolute —— 这种结构本可用 Grid 的 justify-self: end; align-self: start 在一级子项上直接实现。
- 能用
grid-template-areas命名区域的，就别手动写grid-column: 2 / 3配合一堆 class - 外层用
repeat(3, 1fr)划列，内层卡片直接设display: grid并复用轨道（靠subgrid），而不是再包一层div来做“卡片内容区” - 表单 label 和 input 不必拆成两行 div，用
grid-template-columns: [label] 120px [input] 1fr+grid-column: label就够
为什么更少 DOM = 更高渲染性能
浏览器渲染流程中，“Layout”阶段需遍历 DOM 树计算每个节点的几何位置。DOM 层级越深，回流（reflow）成本越高，尤其当 JS 动态修改某子元素尺寸时，可能触发整棵子树重排。
立即学习“前端免费学习笔记（深入）”；
Grid 的显式定义（如 grid-template-rows: 60px auto 50px）让浏览器提前知道整体高度分布，无需逐层测量；而 flex 嵌套三层后，height: 100% 在中间层失效，最终只能靠 JS 补尺寸，进一步加剧不确定性。
-
grid-template-rows写死或用minmax()，比依赖内容撑开的flex: 1更可控 - 避免在 Grid 项里再套
display: grid且未设grid-template-rows—— 这会让该网格项高度变成auto，破坏外层布局节奏 - 现代 Chrome/Firefox 对单层
display: grid+ 单层display: flex嵌套毫无压力；但三层以上（Grid → Flex → Grid）会显著增加样式计算时间，尤其在低端设备上
subgrid 是减少嵌套的捷径，但有硬性前提
subgrid 不是“自动继承父网格”的开关，它只对直系子元素生效，且必须满足两个条件：父容器已声明 display: grid 并定义了 grid-template-columns（或 rows），子元素自身设 display: subgrid 并显式写 grid-template-columns: subgrid。
漏掉任一条件，浏览器会静默退化为普通块级流——你不会看到报错，但布局就崩了。
- 别在
<section>上写display: subgrid却忘了给它的父<main>加grid-template-columns -
grid-template-areas在嵌套中完全失效，因为它不穿透层级；要用subgrid，就得放弃区域命名，改用轨道索引（如grid-column: 2 / 4） - 兼容性兜底不能只靠
@supports (display: subgrid)，IE11 和部分旧安卓 WebView 会彻底忽略该规则，必须配合 CSS 变量 + fallback 布局
真正容易被忽略的是：Grid 的高效不来自语法炫技，而来自“用最少的 DOM 节点承载最多的布局意图”。一旦开始写第二层 wrapper，就该停下来问一句——这个 wrapper 的语义是什么？能不能用 grid-column 或 place-items 直接替代？
