contain: layout paint 是最可靠、最常用的方式，它能明确告诉浏览器“这个区域自己管自己”，让重绘只发生在容器边界内——但前提是容器尺寸稳定、子元素不越界、且浏览器支持该属性。
直接给结论：contain: layout paint 是最可靠、最常用的方式，它能明确告诉浏览器“这个区域自己管自己”，让重绘只发生在容器边界内——但前提是容器尺寸稳定、子元素不越界、且浏览器支持该属性。
为什么 contain: layout paint 是首选组合
单独设 contain: layout 无法阻止子元素样式变更（比如 background-color 或 opacity）引发的父级重绘；只设 contain: paint 又无法隔离布局影响，溢出内容可能仍触发外部绘制逻辑。二者必须同时启用，浏览器才将该元素及其后代视为独立渲染上下文。
-
layout封锁内部尺寸/位置变化对外部的影响（例如列表项高度变，不会导致外层滚动条跳动） -
paint强制裁剪溢出，并跳过不可见区域的绘制（比如折叠面板里被隐藏的内容完全不参与 paint 阶段） - 不要用
contain: content：它等价于layout paint，但不包含style，主题切换或伪类变更时可能泄漏样式计算
哪些 JS 操作会让 contain 失效
Contain 是浏览器的优化提示，不是强制隔离罩。以下操作会直接破坏效果：
- 子元素设
position: fixed或position: absolute且 top/left 依赖父容器计算结果——这类元素会被视为“越界”，paint隔离失效 - 在回调中连续读写同一元素的
offsetHeight和style.height—— 触发强制同步布局（Layout Thrashing），layout隔离白费 - 用
el.scrollIntoView()滚动到容器内某个子项，而该子项用了transform或opacity，又没配will-change—— 浏览器可能放弃合成层，重绘范围扩大 - 动态插入 DOM 后再设置
element.style.contain = 'layout paint'—— 错过首次渲染优化窗口，隔离边界不会回溯生效
contain: size 为什么最容易踩坑
size 要求浏览器“相信”容器尺寸绝不会变。一旦违反，轻则内容被裁剪，重则布局塌陷为 0×0。
- 不能和
height: auto、flex: 1、min-content共存——这些值依赖内容推导尺寸，与size的前提冲突 - JS 动态设置时，必须同步显式写死
width和height（哪怕用getComputedStyle反查当前值再赋回去） - Safari 15.4+ 对
size的实现仍有偏差，生产环境建议加特性检测：if ('contain' in document.documentElement.style) - React/Vue 组件若根据 props 动态改高，加
size后子元素可能直接消失
真正起效的关键不在“写了什么”，而在“什么时候写、写在哪、有没有破坏前提”。尺寸不稳定、子元素逃逸、JS 强制读取布局——这三个点任何一个出问题，contain 就会退化成普通样式声明。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
