应动态设置contain的场景包括：下拉菜单插入大量子项前、虚拟滚动首次渲染可视区、折叠面板收起后移除contain、resize时为固定尺寸工具栏补contain；contain:size易出错因要求尺寸绝对稳定，JS操作需同步显式设置宽高且禁用flex:1等依赖内容推导的值。
能显著减少局部渲染的布局开销，但必须满足容器尺寸可控、子元素不逃逸、浏览器支持等前提；盲目加 contain: strict 可能导致布局错乱或性能反降。
什么时候该用 JS 动态设置 contain 而不是纯 CSS？
纯 CSS 写死 contain 适合结构稳定、尺寸明确的模块（如固定高卡片、弹窗内容区）。JS 动态控制则用于以下真实场景：
- 下拉菜单展开前：先设
element.style.contain = 'layout paint'，再批量插入 50+ 个<li>，避免插入过程触发父级重排 - 虚拟滚动容器首次渲染可视区域时：调用
container.style.contain = 'layout paint'，后续滚动中子项高度变化不再影响外层滚动条计算 - 折叠面板收起后：移除
contain（设为空字符串），避免contain: size锁死高度导致动画无法收缩 - 监听
resize时对工具栏补contain: layout paint，防止窗口缩放时整页重排——但仅限已知宽高固定的区域，动态宽度侧边栏不能加size
contain: size 为什么最容易出问题？
contain: size 要求浏览器“相信”该元素尺寸绝不会变，一旦违反，布局会直接失效。JS 操作时尤其危险：
- 必须同步显式声明
width和height（哪怕用getComputedStyle反查当前值再写回） - 禁止在含
size的容器内使用flex: 1、min-content、fit-content等依赖内容推导尺寸的值 - React/Vue 中若组件有
height: auto或根据 props 动态改高，加size后会导致子元素被裁剪或溢出 - 调试时用
getComputedStyle(el).contain检查是否生效，旧版 Safari（size 实际未启用
哪些 JS 行为会让 contain 失效？
Containment 不是隔离罩，而是浏览器的优化提示。以下 JS 操作会直接破坏隔离效果：
立即学习“前端免费学习笔记（深入）”；
- 子元素设置
position: fixed且未指定contain: paint—— 固定定位参照物默认是视口，逃逸出容器边界，绘制隔离失效 - 用
el.scrollIntoView()滚动到容器内某个子项：若该子项用了transform或opacity，而容器没配will-change，浏览器可能放弃合成层，重绘范围扩大 - 通过
getBoundingClientRect()强制读取子元素位置：这会触发强制同步布局（Layout Thrashing），使contain: layout的优化完全白费 - 在
requestAnimationFrame回调里连续修改同一元素的width和height：即使容器有contain: strict，多次写入仍会累积触发重排
真正起效的关键不在“加了什么”，而在“没让什么发生”——比如避免 position: absolute 子元素的 top 值依赖父容器计算结果，或确保 resize 监听器里只改样式类而不读取 offsetHeight。这些细节比选哪个 contain 值更决定最终性能。
