contain: size仅隔离容器尺寸计算，子元素变化不影响其宽高，但不阻止重排；contain: layout则创建独立布局上下文，彻底隔离内外布局影响，但开销更高且禁用部分优化。
contain: size 和 contain: layout 有什么区别？
contain: size 告诉浏览器：“这个容器的尺寸是固定的，你不用等它的子元素渲染完就能算出它占多大位置。”但它不阻止子元素触发重排；而 contain: layout 更进一步：它把容器变成一个独立布局上下文，子元素的尺寸变化、浮动、绝对定位等都不会影响外部布局——但代价是浏览器必须为它单独建立布局树节点，开销略高。
-
contain: size必须配合contain-intrinsic-size才能生效，否则只是个空声明 -
contain: layout不依赖contain-intrinsic-size，但会禁用某些优化（如部分 margin 合并） - 实际项目中，卡片列表项常用
contain: layout，而图片占位容器倾向用contain: size
为什么写了 contain 却没看到性能提升？
常见现象：加了 contain: layout 或 contain: size，Lighthouse 的“Avoid large layout shifts”评分没变，甚至滚动卡顿更明显了。
- 容器用了
display: inline或display: inline-block——contain在非块级/非 flex/grid 容器上被忽略 - 父容器高度由该容器撑开（比如父级是
min-height: auto），形成循环依赖，浏览器 fallback 到无约束行为 - 容器内有未设宽高的
img或iframe，它们加载时仍会触发布局偏移，contain无法拦截这种外部资源加载副作用 - DevTools 的 Layers 面板里看不到新图层 → 说明
contain没真正激活，先检查 computed 样式中是否显示contain: layout（不是contain: none）
contain 和 content-visibility: auto 能一起用吗？
可以，而且推荐在长列表场景下组合使用。
-
content-visibility: auto会让浏览器跳过不可见区域的布局和绘制，但不隔离样式作用域；子元素的 CSS 仍可能影响外部（比如 :focus-visible 伪类、动画触发器） - 加上
contain: style后，可确保子树的样式计算完全隔离，避免意外继承或层叠污染 - 注意顺序：
content-visibility: auto必须搭配contain-intrinsic-size（哪怕设为auto），否则首次渲染可能塌陷 - 示例写法：
.list-item { content-visibility: auto; contain: layout style; contain-intrinsic-size: auto 200px; }
移动端兼容性有哪些硬伤要提前防？
iOS Safari 对 contain 的支持从 iOS 15.4 开始，旧版本（包括 iOS 14.x 全系）会静默忽略整个声明，不报错也不降级。
立即学习“前端免费学习笔记（深入）”；
- 不要用
@supports (contain: layout)做功能检测 → 它在 Safari 15.3 及更早返回true，但实际无效 - 真实可用的检测方式是 JS 判断：
getComputedStyle(el).contain === 'layout'，再结合el.getLayoutBounds()是否存在 - Android WebView（Chrome 90 之前）同样存在 partial support 问题，建议对
contain: paint单独做降级（比如用will-change: transform替代） - 最容易被忽略的一点：
contain: strict在所有已支持浏览器中都等价于contain: layout paint style，但 Safari 15.4–16.0 对strict解析不稳定，宁可拆开写
复杂点不在语法，而在边界条件——比如一个 contain: layout 容器里嵌套了 position: sticky 子元素，sticky 行为会失效；又比如它内部用了 CSS 自定义属性动态控制 display，可能导致 contain 上下文意外销毁。这些都不是文档里明说的限制，而是实测出来的行为断点。
