grid嵌套超2层会导致布局计算爆炸，android 5.1 webview中单次getcomputedstyle耗时达8ms+并引发掉帧；根本原因是每层新增display: grid都会触发隐式轨道生成、grid-template-areas解析及行列映射，3层后形成循环依赖与多轮重排。
Grid嵌套超过2层后，DOM结构和CSS逻辑开始互相绑架
不是“写起来麻烦”，而是每多一层 display: grid，你就多承担一份隐式约束：父容器尺寸可能被子内容反向决定，子项的 grid-row 和 grid-column 会触发上溯验证，浏览器在 DevTools 的 Rendering 面板里频繁打出 “Layout” 事件。你改一行 CSS，控制台突然卡顿两秒——这不是机器慢，是 layout 引擎在循环求解。
- 三层嵌套常见于：卡片组件自己设
display: grid，里面图标+文字再套一层grid对齐，而卡片又放在外层网格列表中 - 这种写法让
minmax(min-content, 1fr)变成定时炸弹：只要某处文本换行或图片加载完成，就可能引发多轮重排 - 更隐蔽的问题是调试断点失效——你给子项加
border，发现它没显示，其实是中间层容器用了overflow: hidden或contain: strict，但你根本没意识到那层存在
用 display: contents 替代“仅为了对齐”的Grid包裹层
很多所谓“必须嵌套”的场景，其实只是想让按钮靠右、标题居中、图标对齐文字基线。这些完全不需要新增 DOM 节点或布局上下文。
- 把原本的
<div class="card"><div class="card__header"><h2>标题</h2></div></div>改为直接<h2 class="card__title"></h2>，并在父容器上设display: grid -
card__title加justify-self: center或align-self: end，按钮加justify-self: end，全部直接受控于外层网格 - 注意兼容性：
display: contents在 iOS Safari 15.4+、Chrome 65+、Firefox 63+ 支持；旧版需 fallback 为visibility: hidden+position: absolute占位 - 禁用在
<input>、<button></button>等表单控件上——它们会失去可访问性和 focus 状态
subgrid 不是自动魔法，但能砍掉重复轨道定义
subgrid 不会让嵌套消失，但它把“子网格要和父网格对齐”这件事从手动复制变成继承声明。前提是父容器已明确定义了轨道，且子元素显式启用 subgrid。
- 外层写
grid-template-columns: 1fr 3fr 1fr，子卡片只需grid-template-columns: subgrid+grid-column: 2 / 4，它的子元素就能用grid-row: 3直接对齐到父网格第 3 行 - 漏掉任一条件（比如父没设
grid-template-columns，或子没写display: grid），浏览器就静默退化为普通块级流，不会报错也不会提示 - 必须配合
@supports (display: subgrid)做渐进增强；不支持时 fallback 到grid-template-areas+display: contents组合 -
grid-template-areas在嵌套中天然失效——区域命名只作用于直系子元素，孙子节点无法参与映射
真正卡住开发节奏的，往往是选择器和 DOM 的双重错位
你删掉三层 div，但 CSS 还写着 .page .main .card .header .title，浏览器照样从 .title 往上查四层。性能瓶颈不在 HTML 深度，而在选择器是否强制回溯。
- BEM 类名如
card__title必须显式出现在 HTML 中，否则.card__title { }规则永不生效 - SCSS 里的
&__title编译结果取决于空格位置：.card { &__title { } }→.card__title，但.card { .header { &__title { } } }→.header__title，语义断裂 - 构建后用
grep -r "\.[a-z]\+ \.[a-z]" dist/扫描残留空格选择器，4 层及以上就是实测卡顿起点 - 媒体查询里禁用
&嵌套：一旦外层有缩进，@media内的&__body会展开全部路径，产出不可控的长选择器
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
