<p>contain 在 Safari 15.4 前、所有 IE 及 Android 9- Webview 中完全不识别，整条规则被丢弃；检测需看 DevTools 中规则是否显示；构建时按 browserslist 移除或注释更可靠；content-visibility: auto 可替代部分场景但不支持 paint 级隔离。</p>
contain 属性在 Safari 15.4 之前、所有 IE 版本、部分 Android Webview（如 Android 9 及更早）中完全不被识别，且不会静默降级，而是直接忽略整条规则——这意味着你写的 .list { contain: layout style; } 在这些浏览器里等于没写，可能导致布局重排失控或性能骤降。
contain 不生效时，先确认是不是被浏览器彻底跳过
打开 DevTools → Elements 面板 → 找到目标元素 → 看 Styles 标签页：
- 如果该规则根本没出现（不是被划掉，是压根不显示），说明浏览器解析阶段就丢弃了含
contain的整条声明； - 如果出现但属性值显示为灰色并标 “invalid”，说明语法被识别但不支持（极少见，基本只发生在拼错值如
contain: layot;）； -
@supports (contain: layout)在 Safari 15.3 及更早版本中返回 false，但不能依赖它做运行时开关——因为 JS 检测到不支持后插入的 fallback CSS，仍可能因构建/注入时机问题未及时生效。
构建时条件编译比运行时检测更可靠
contain 是纯渲染优化型属性，无视觉副作用，因此不建议用 JS 动态加 class 或 patch 样式。更稳的做法是在构建阶段按 browserslist 切割输出：
- 使用 PostCSS 插件（如
postcss-contain或自定义postcss-plugin）识别contain声明，并在目标环境不支持时：- 直接移除该行（对 layout/style/paint 级别 containment）；
- 或替换为注释（如
/<em> contain: layout; ← removed for Safari <= 15.3 </em>/），便于 QA 审计；
- Vite 用户可配
vite-plugin-css-legacy，Webpack 用户用postcss-preset-env并确保其stage≥ 3 且features显式启用contain； - 注意：Autoprefixer 不处理
contain，它只管厂商前缀，别指望它帮你兼容。
用 content-visibility: auto 替代部分 contain: layout style 场景
content-visibility: auto 在 Chrome 85+、Edge 85+、Firefox 103+、Safari 16.4+ 支持，覆盖范围略优于 contain，且具备类似“子树渲染隔离”效果：
立即学习“前端免费学习笔记（深入）”；
- 它隐式启用 layout/style containment（无需显式写
contain）； - 对滚动容器内长列表（如无限滚动 feed）效果接近，且自带 offscreen rendering 优化；
- 但它不等价于
contain: paint，无法阻止元素溢出裁剪或动画重绘穿透； - 若需
contain: paint效果（如防止 fixed 元素被遮挡、限制 canvas 动画影响范围），目前无 CSS 替代方案，只能接受降级或用transform: translateZ(0)+will-change: transform组合触发合成层——但这会增加内存开销，慎用。
旧版浏览器里，contain 的缺失通常不会导致功能错误，但可能暴露底层性能瓶颈。真正要盯紧的，是那些依赖它做“渲染隔离”的场景——比如模态框打开时页面仍疯狂重排，或虚拟滚动列表卡顿加剧。这种时候，别只盯着能不能加 contain，先检查是否本就不该让那个区域参与主线程布局。
