Flex容器嵌套超三层会真实触发Chrome Layout超时，因每层需独立主轴/交叉轴遍历，三层后Layout耗时常突破16ms/frame，引发滚动卡顿和layout thrashing；应扁平化结构、用gap/margin替代冗余flex层、显式设置align-self、对直接子项启用contain: layout，并避免align-items: stretch连锁重排。
Flex容器嵌套超三层直接触发Layout超时
这不是“看起来卡”，而是Chrome Layout阶段真实突破16ms/frame阈值。每多一层display: flex，浏览器就得单独跑一次主轴+交叉轴遍历——三层嵌套后，.list-wrapper → .row → .card → .content → .avatar这种结构会让Layout耗时陡增，滚动时频繁报layout thrashing警告。
验证方式很简单：打开 Chrome DevTools → “Rendering” 面板 → 勾选 “Layout Shift Regions”，高亮区域越大，说明嵌套越深、重排越失控。扁平化后它会立刻收缩。
- 把中间冗余层（如
.row、.content）改成普通div，用gap或margin控距 -
.card必须是.list-wrapper的直接子项，不包任何额外flex容器 - 图标类元素写
flex: 0 0 24px，文字区写flex: 1，别再套一层flex
flex-wrap + 大量子项触发O(n²)布局算法
当flex-direction: row配合flex-wrap: wrap且子项超过200个时，浏览器对换行位置和尺寸重算的复杂度接近O(n²)。这不是CSS写法问题，而是底层实现限制——每次滚动都要重测所有可见+临近项的flex-basis、grow/shrink权重、换行断点。
getComputedStyle(el).display返回flex才真正生效；若父级用了display: contents或CSS-in-JS注入顺序错乱，它可能悄悄fallback成block，反而让性能更差。
立即学习“前端免费学习笔记（深入）”；
- 优先用
content-visibility: auto跳过不可见项的布局计算（需配contain-intrinsic-size: 40px） - 禁用
height: auto或min-height: fit-content，否则content-visibility直接退化 - 含
position: sticky子项的容器不能加content-visibility，它会强制全量layout
align-items: stretch在深层嵌套中引发连锁重排
这个默认值会让每个子项强制拉伸并重新测量内容高度。一旦嵌套两层以上flex容器，就容易形成layout cascade：父容器stretch → 子项重测高度 → 子项内嵌flex容器再次stretch → 再次重测……每张卡片都在反复执行这套流程。
iOS Safari 12–14对此尤其敏感，下拉刷新后可能直接卡死，不是bug而是渲染引擎缓存失效机制缺陷。
- 对头像、图标等固定尺寸区域，显式设
align-self: flex-start或flex: none - 需要视觉拉伸的内容，改用
min-height或aspect-ratio，避开stretch的测量逻辑 - 绝对不要在卡片根容器上写
align-items: stretch，哪怕你没显式声明，它也是默认值
contain: layout只对直接子项生效，加错位置反而坏事
contain: layout的作用是告诉浏览器：“这个元素内部怎么变，都不会影响外面”。但它只对flex容器的**直接子项**有效——加在容器本身、动画按钮、或will-change: transform元素上，不仅无效，还可能破坏渲染连贯性。
适合加的位置只有那些语义独立、尺寸稳定的块：.card、.item、弹窗内容区。IE完全不支持，但IE本就不该跑大数据量Flex列表。
- 别给
.list-container自身加contain: layout - 正在做
transform动画的按钮不能加，冲突会导致will-change被忽略 - 确保目标元素没有动态改变
height或width，否则contain效果会失效
