三层以上flex嵌套导致chrome layout超16ms，因每层需完整主轴+交叉轴遍历，耗时非线性翻倍；应扁平结构、固定尺寸、显式flex-basis，并用contain隔离重排影响。
大量 Flex 元素卡顿，核心问题不是“用了 Flex”，而是布局树过深、弹性计算失控、重排扩散无约束——优化关键在扁平结构、固定尺寸、隔离影响范围。
为什么三层以上 Flex 嵌套会让 Chrome Layout 超 16ms
每层 display: flex 容器都会触发一次完整的主轴+交叉轴遍历，三层嵌套不是线性叠加，而是 Layout 阶段耗时翻倍。滚动或动态插入时，layout thrashing 报警频发，尤其在低端设备上帧率骤降。
- 典型坏结构：
.list → .item → .content → .avatar，其中.content只是空 div 却设了display: flex - 验证方式：Chrome DevTools → Rendering → 勾选
Layout Shift Regions，高亮区域越大，嵌套越深 - 解法：把中间层（如
.content）改成普通<div>，用 <code>gap或margin控制间距；图标用flex: 0 0 24px，文字区用flex: 1 1 0flex: 1 是性能黑洞，不是语法糖
flex: 1等价于flex: 1 1 0，意味着所有空间从零开始分配，浏览器必须反复测量内容再重算。列表项超过 50 个，这个动作就会成为重排引擎。- 固定尺寸优先：头像、图标等明确宽高的元素，直接写
flex: 0 0 32px，跳过弹性计算 - 避免混用：
flex: 1和width: auto同时存在，会让flex-basis退化为auto，触发额外内容度量 - 需自适应时，用
flex: 1 1 max-content比flex: 1更稳，防文字换行抖动
align-items: stretch 在深层结构里会引发连锁重排
这个默认值会让子项强制拉伸并重新测量高度。一旦嵌套两层以上 Flex 容器，就容易形成「父 stretch → 子重测 → 子内 flex 再 stretch → 再重测」的循环。
- 常见场景：卡片组件用
flex-direction: column包裹标题+描述+按钮，外层又没关align-items: stretch - 解法：对固定高度区域（如头像）显式设
align-self: flex-start；对需撑满的区域，改用min-height或aspect-ratio - iOS Safari 12–14 对此缓存失效更严重，下拉刷新后可能直接卡死
用 contain: layout 隔离重排，但只对直接子项有效
contain: layout style paint告诉浏览器：“这个元素内部怎么变，都不会影响外面”。它能大幅压缩重排扩散范围，但只对 Flex 容器的直接子项生效。- 适合加在语义独立、尺寸稳定的块上，比如
.card、.item、弹窗内容区 - 不要加在
.list-container自身，也不要加在正在做transform动画的按钮上 - 兼容性：Chrome 52+、Firefox 69+、Safari 15.4+；IE 完全不支持
最容易被忽略的是：DOM 层级和选择器嵌套不是一回事。即使删光了多余 div，若还写
.page .header .nav .item这类四层选择器，浏览器仍要从右往左逐层回溯匹配，开销成倍增加。 - 固定尺寸优先：头像、图标等明确宽高的元素，直接写
