contain:layout 能减少重排，因为它将元素设为独立布局上下文，子元素的尺寸和定位变化不再触发父级或祖先节点的 layout 计算，从而避免向上遍历检查影响。
contain:layout 为什么能减少重排
它强制浏览器把该元素当成一个独立的布局上下文，子元素的 position、width、height、margin 等变化，不再触发父级或祖先节点的 layout 计算。浏览器不用再向上遍历检查“这个改动会不会影响我上面那个容器的高度？”——直接跳过。
常见错误现象：
- 动态添加/删除列表项时，整个列表区域抖动或滚动卡顿
- 用
transform模拟位移但仍有 layout 触发（比如同时改了top或left） - Chrome DevTools 的 Rendering 面板里频繁看到
Layout事件标红，且调用栈指向父容器
contain:layout 对盒模型的实际限制
它不改变元素自身的盒模型计算方式，但切断了内外双向的 layout 依赖链：
- 子元素的
float、absolute定位不会影响父元素的 content-box 尺寸 - 父元素的
display: flex或grid不再“感知”子元素的min-content或max-content贡献 - 外部的
font-size变更、zoom、媒体查询切换，不会重新触发该元素内部的 layout - 但注意：
contain:layout不阻止overflow、border、padding这些自身盒模型属性的正常生效
和 contain:size、contain:paint 搭配使用的必要性
contain:layout 单独用效果有限，容易踩坑：
- 如果子元素撑大了父容器，而你又没设
height或min-height，父容器可能视觉上“消失”——因为layout不管尺寸，只管布局传播 - 子元素溢出父边界时，
contain:layout不会裁剪，得加contain:paint或overflow:hidden - 推荐组合：
contain: layout paint（即contain:content），既隔离 layout 影响，又防止绘制越界 - 若父容器尺寸固定且不允许子内容撑开，再补上
contain:size；否则慎用，否则高度可能塌陷为0px
移动端长列表中 use strict 还是 content
在虚拟滚动或无限加载场景下，contain:strict 表面看更“彻底”，但实际有副作用：
-
contain:strict包含size，意味着浏览器完全忽略子元素对父尺寸的贡献 —— 如果列表项高度不固定（比如图文混排、字体加载中），父容器会保持初始height:0，导致内容不可见 -
contain:content（layout + paint）更实用：保留尺寸计算，只隔离 layout 和 paint 传播，滚动时仍能正确测量可见项高度 - iOS Safari（截至 2026 年 4 月）对
contain:strict支持不稳定，X5 内核（微信/QQ）基本不支持size，但content兼容性好得多
真正难处理的是子元素内部的 layout 变动是否可预测——如果连高度都靠 JS 动态测，那 contain 的收益会打折扣，优先保证结构可控比硬套属性更重要。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
