flex嵌套超三层导致chrome layout阶段真实耗时超16ms/frame，引发layout thrashing；应扁平化结构、禁用align-items: stretch、合理使用contain: layout与content-visibility: auto，并限制css选择器嵌套≤3层。
Flex嵌套超三层就卡，Chrome Layout阶段真会超16ms/frame
这不是“看起来慢”，而是浏览器在Layout阶段真实耗时突破帧预算。每多一层display: flex，Chrome就要单独跑一次主轴+交叉轴遍历；三层嵌套后（比如.list-wrapper → .row → .card → .content → .avatar），滚动时频繁触发layout thrashing警告，iOS Safari 12–14甚至下拉刷新后直接卡死。
验证方式极简单：打开 Chrome DevTools → “Rendering” 面板 → 勾选 “Layout Shift Regions”。嵌套越深，高亮区域越大；扁平化后立刻收缩。
- 把中间冗余层（如
.row、.content）改成普通<div>，用<code>gap或margin控制间距 -
.card必须是.list-wrapper的直接子项，不包任何额外flex容器 - 图标类元素写
flex: 0 0 24px，文字区写flex: 1，别再套一层flex - 对头像、图标等固定尺寸区域，显式设
align-self: flex-start或flex: none - 需要视觉拉伸的内容，改用
min-height或aspect-ratio，避开stretch的测量逻辑 - 禁用
height: auto或min-height: fit-content，否则content-visibility: auto会直接退化 - 适合加在语义独立、尺寸稳定的块上，比如
.card、.item、弹窗内容区 - 不要加在
.list-container自身，也不要加在position: sticky子项的父容器上 - 配合
content-visibility: auto使用时，必须配contain-intrinsic-size: 40px - 真实项目中，超过3层嵌套（
&嵌套）就该警惕 - 把嵌套层级锁死在 ≤3 层：DOM 上最多
<section><div class="grid">，再往里就用语义化子类（如<code>card__header）替代.card > header - 禁用框架的全局过渡动画：
transition: all替成transition: transform 0.2s, opacity 0.2s
真正卡顿的根源往往不在“写法错”，而在“结构冗余”——比如一个
align-items: stretch 在深层嵌套里会引发连锁重排
这个默认值会让子项强制拉伸并重新测量内容高度。一旦嵌套两层以上flex容器，就容易形成 layout cascade：父容器stretch → 子项重测高度 → 子项内嵌flex容器再次stretch → 再次重测……每张卡片都在反复执行这套流程。
contain: layout 只对 flex 直接子项有效
它告诉浏览器：“这个元素内部怎么变，都不会影响外面”，能大幅减少重排扩散范围。但它只对flex容器的直接子项生效，加在容器本身或正在做transform动画的按钮上反而破坏渲染连贯性。
移动端 CSS 选择器嵌套过深会拖慢匹配性能
浏览器解析 CSS 是从右向左匹配的。SCSS 中一个& .header .title .icon编译后可能产出冗余组合，5层嵌套常生成20+类名变体，CSS体积膨胀、调试困难，低端 Android 设备上还会显著拖慢重排重绘延迟。
.avatar被包在五层flex里，又同时依赖calc() + align-items: stretch + position: sticky，这时候删掉两层容器比调任何属性都管用。
