contain: strict 经常不生效是因为 size containment 要求容器有可预测尺寸，若高度由内容撑开（如 height: auto）则被浏览器静默忽略；它还会使 absolute/fixed 元素的包含块降级为自身，并与 content-visibility: auto 分层配合使用才有效。
contain: strict 为什么经常“不生效”
直接写 contain: strict 很可能被浏览器静默忽略——这不是 bug，是规范强制要求。它等价于同时启用 layout、paint、size 和 style，而其中 size 要求容器必须有**可预测的尺寸边界**。如果容器高度由内容撑开（比如没设 height 或 min-height），Chrome 和 Safari 都会直接放弃整个 containment，降级为无效果。
常见失效写法：
-
.list-item { contain: strict; }—— 没尺寸约束，白加 -
.card { contain: strict; width: fit-content; }——fit-content让尺寸依赖子内容，破坏size的前提
真正生效的底线：至少得有 min-height 或 height，且不能是 auto、fit-content、max-content 这类动态值。
contain: strict 对 position: absolute/fixed 元素的影响
它不会“限制”父级对子元素的定位控制，但会切断子元素对外部布局上下文的依赖。一旦父容器用了 contain: strict，其内部的 position: absolute 元素将无法再以文档流中更外层的祖先作为包含块（containing block）——它的包含块会被强制降级为该 strict 容器自身。
立即学习“前端免费学习笔记（深入）”；
这意味着：
-
top: 0; left: 100%不再相对于视口或 body，而是相对于 strict 容器左上角 -
position: fixed在 strict 容器内会退化为position: absolute，因为 fixed 的锚点（viewport）被隔离了 - 若 strict 容器本身是
transform或will-change触发的合成层，其内部fixed元素可能完全错位
所以别给弹窗根容器或全局导航栏加 strict，除非你明确要把它变成一个“iframe 式沙盒”。
contain: strict 和 content-visibility: auto 能否一起用
能，但必须分层，且顺序和目标要严格区分：
-
content-visibility: auto应用于**整页列表容器**（如.infinite-list），配合contain-intrinsic-size让浏览器跳过不可见区域的样式/布局计算 -
contain: strict应用于**单个列表项**（如.list-item），前提是每个项都有固定高度（height: 80px）或最小高度（min-height: 80px） - 绝对不要在同一个元素上同时写
content-visibility: auto和contain: size—— 二者对尺寸推导逻辑冲突，会导致contain-intrinsic-size失效
典型结构：
.infinite-list {
content-visibility: auto;
contain-intrinsic-size: 80px;
}
.list-item {
contain: strict;
height: 80px; /* 必须显式 */
}contain: strict 在滚动长列表中的真实代价
它确实能减少重绘范围，但不是零成本：
- 每个 strict 容器都会创建新的层叠上下文和 BFC，大量使用会增加内存占用（尤其在低端 Android 设备上）
- 若 strict 容器内有
transform动画或频繁opacity切换，浏览器可能被迫为每个项单独建合成层，反而加剧 GPU 压力 - 调试困难：DevTools 的 Layout 窗格里看不到 strict 容器内部的布局细节，
getComputedStyle()读取某些属性（如offsetHeight）可能返回 0 或旧值
最易被忽略的一点：strict 不解决 flex/grid 容器内的弹性分配问题。如果列表用 display: flex; flex-direction: column，新增一项仍会让所有兄弟重新计算剩余空间——containment 无法切断这种跨边界协调逻辑。
