Flex容器嵌套超三层会显著拖慢渲染，因每层需单独主轴/交叉轴布局遍历，Chrome Layout阶段常超16ms/frame引发滚动卡顿；align-items: stretch在深层嵌套中易触发连锁重排；应扁平化结构、显式设置align-self、用contain: layout隔离布局影响，并避免滥用flex: 1。
Flex容器嵌套超三层就卡，不是错觉而是Layout阶段超时
Chrome Layout 阶段耗时超过 16ms/frame 是真实瓶颈，不是“看起来慢”。每多一层 display: flex，浏览器就要额外做一次主轴+交叉轴遍历，三层嵌套后滚动卡顿、layout thrashing 报警就会频繁触发。典型坏结构如 .list-wrapper → .row → .card → .content → .avatar，其中 .row 和 .content 都是冗余 flex 容器。
验证方式很简单：打开 Chrome DevTools → “Rendering” 面板 → 勾选 “Layout Shift Regions”，嵌套越深，高亮区域越大；扁平化后会明显收缩。
- 把中间层（如
.row、.content）改成普通div，用gap或margin控制间距 -
.card直接作为.list-wrapper的子项，不再包多层 flex 容器 - 图标类元素用
flex: 0 0 24px，文字区用flex: 1，避免额外包裹
align-items: stretch 在深层嵌套里会引发连锁重排
这个默认值会让子项强制拉伸并重新测量内容高度，一旦嵌套进两层以上 flex 容器，就容易形成 layout cascade：父容器 stretch → 子项内容重测 → 子项内嵌 flex 容器再次 stretch → 再次重测……
常见场景是卡片组件里用 display: flex; flex-direction: column; 包裹标题+描述+按钮，又在外层加了 align-items: stretch，导致每张卡片都反复计算高度。
- 对固定高度区域（如头像、图标）显式设
align-self: flex-start或flex: none - 对需要视觉拉伸的内容，改用
min-height或aspect-ratio，避开stretch的测量逻辑 - iOS Safari（尤其 12–14）对此更敏感，下拉刷新后可能直接卡死
contain: layout 只对 flex 直接子项有效
它告诉浏览器：“这个元素内部怎么变，都不会影响外面”，能大幅减少重排扩散范围。但它只对 flex 容器的**直接子项**生效，加在容器本身或动画元素上反而破坏渲染连贯性。
- 适合加在语义独立、尺寸稳定的块上，比如
.card、.item、弹窗内容区 - 不要加在
.list-container自身，也不要加在正在做transform动画的按钮上 - 兼容性：Chrome 52+、Firefox 69+、Safari 15.4+；IE 完全不支持
选择器嵌套和 DOM 层级不是一回事，别只删 div
很多人以为“删掉多余 div 就行”，但真正拖慢的是 CSS 选择器匹配逻辑——浏览器从右往左查，每多一层父级验证，回溯开销就成倍增加。即使 DOM 只有一层，如果还写 .page .header .nav .item a，照样卡。
- 用 BEM 命名把语义“编译”进类名：
product-card__title而非.card .title - SCSS 中慎用
&嵌套，该提级时用@at-root，避免生成深层选择器 - 移动端构建时特别注意：esbuild 处理 10 层 SCSS 嵌套可能生成 10 万种组合，直接内存溢出
最易被忽略的是：contain: layout 加错位置、align-items: stretch 在多层 column 布局里反复触发重测、以及选择器权重掩盖了 DOM 扁平化的实际收益——这三处不动，光调 justify-content 没用。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
