flex嵌套≥4层且含多层flex容器即达性能瓶颈；应通过devtools查看nodedepth确认，用flex:0 0 32px、flex:1 1 max-content替代flex:1，配合contain:layout隔离重排，警惕框架隐式嵌套。
Flex嵌套超过三层，滚动卡顿、Layout耗时超16ms/frame就不是错觉，而是真实可测的性能瓶颈。
怎么快速确认自己是不是踩了嵌套坑
打开 Chrome DevTools → Elements 面板 → 右键任意疑似 Flex 容器（比如 .card 或 .list-item）→ 选“Show DOM properties” → 查看 nodeDepth 值。如果 ≥ 4，且该节点本身是 display: flex，再往上还有两层 flex 容器，基本就超限了。
- 别只看 HTML 里写了几个
<div>，重点看实际生效的 <code>display: flex层级 -
align-items: stretch在嵌套中会放大问题——它会让每层子项都重测高度，形成连锁重排 - iOS Safari 12–14 对这种嵌套特别敏感，下拉刷新后可能直接卡死，不报错但无响应
- 图标、头像等固定尺寸元素，直接写
flex: 0 0 32px，跳过弹性计算 - 文字区域需要自适应时，用
flex: 1 1 max-content替代flex: 1，防换行抖动 - 避免混用
flex: 1和width: auto——后者会让flex-basis退化为auto，强制多一次内容度量 - 适合加在语义独立、尺寸稳定的块上，比如
.card、.item、弹窗内容区 - 不要加在
.list-container自身，也不要在做transform动画的按钮上加，反而破坏渲染连贯性 - 兼容性：Chrome 52+、Firefox 69+、Safari 15.4+；IE 完全不支持
把 flex: 1 换成更可控的弹性值
flex: 1 看似省事，实际等价于 flex: 1 1 0，浏览器必须从零开始分配空间，反复测量内容宽度，列表滚动时极易触发 layout thrashing。
用 contain: layout 隔离重排影响范围
它告诉浏览器：“这个元素内部怎么变，都不会影响外面”，能大幅压缩重排扩散范围——但只对 flex 容器的直接子项生效。
真正难的不是知道要扁平化，而是识别那些“看不见的嵌套”——比如框架组件自动注入的 wrapper、SSR 模板层层 include 生成的 <div><table><tr><td> 结构，或者 <code>display: contents 虽然视觉上没盒，但仍在样式匹配链里参与回溯。这些地方不进 DevTools 点开看，很容易漏掉。
