contain: layout 能隔离子元素布局变化对父容器的影响，避免父级重排；但禁用 height: auto 等依赖内容的尺寸计算，且不适用于 flex/grid 容器。
直接说结论：用 contain 属性声明渲染边界，能显著减少浏览器不必要的布局重算和绘制，但必须按需选值、避开陷阱，否则可能白加甚至引发错位。
contain: layout 能解决什么问题？
当子元素频繁改变尺寸或位置（比如动画、动态列表项高度变化），父容器会反复重排——哪怕它本身没动。加 contain: layout 后，子元素的布局变化被“锁死”在内部，父容器不再重新计算自身位置和大小。
- 适用场景：虚拟滚动容器、弹窗浮层、可折叠面板的外层 wrapper
- 不适用场景：父容器需要根据子内容自动撑高（如
height: auto的卡片容器）——contain: layout会让它忽略子元素高度，变成 0 高 - 常见错误：给
display: flex或grid容器加contain: layout后子项排列异常，因为 flex/grid 的布局逻辑依赖外部上下文，隔离后失效
contain: paint 最容易被误用的地方
contain: paint 的核心是“裁剪绘制区域”，但它不控制是否可见，只控制“画不画”。如果元素本身溢出父容器又没设 overflow: hidden，它仍可能把内容画到外面去，只是浏览器会强制裁掉。
- 必须配合
overflow: hidden或明确尺寸使用，否则视觉上可能突然消失或错位 - 适合固定位置组件：悬浮按钮、右下角通知栏、模态框遮罩层
- 不能用于需要
box-shadow溢出、transform移出边界的动画——那些效果会被硬裁剪 - 注意：Chrome 120+ 对
contain: paint下的will-change: transform有优化，但 Safari 17.5 仍存在部分绘制残留
strict 和 content 到底该选哪个？
contain: strict 等价于 layout paint size，contain: content 是 layout paint。区别关键在 size：它强制容器尺寸与子内容无关，即子元素再怎么变，父容器宽高都不响应。
- 用
strict前必须确保容器有显式宽高（width/height或min-height），否则可能塌陷 -
content更安全，适合大多数动态卡片、列表项——保留尺寸响应性，只隔离布局和绘制 - 不要对
body或根级容器加strict，它会破坏文档流基准，导致position: fixed错位、滚动条异常
兼容性和运行时检测怎么做？
所有现代浏览器（Chrome 52+、Firefox 59+、Safari 15.4+）都支持 contain，但 Safari 对 contain: size 的实现仍有偏差：子元素 font-size 变化时，父容器可能未正确锁定高度。
- 简单检测：
if ('contain' in document.documentElement.style) - 渐进增强写法：先写基础样式，再用
@supports (contain: layout)包裹优化规则 - 避免和
display: contents同时使用——两者都会破坏盒模型，叠加后布局完全不可控 - 真实项目中，建议从单个高频更新组件（如实时消息列表）开始加
contain: content，用 Performance 面板对比 Layout 时间下降是否明显
真正难的不是加 contain，而是判断哪一层 DOM 节点该加、加什么值、以及加完后是否悄悄破坏了原本依赖流式行为的交互逻辑。测之前先问一句：这个容器，真的“独立”吗？
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
