contain属性在iOS 15.4前及Android WebView≤Chrome 89中存在严重解析缺陷，会导致元素不渲染、高度塌陷或子项错位；UC/QQ X5内核直接忽略该声明。
contain 属性在部分移动端浏览器（尤其是旧版 Safari 和 Android WebView）上会直接导致布局错乱或样式丢失，不是写法问题，而是引擎不支持或解析异常——遇到就该绕开，别硬扛。
哪些移动端浏览器实际不支持 contain
contain: layout / paint / size 在 iOS 15.4 之前、Android WebView ≤ Chrome 89 中存在严重解析缺陷：元素可能完全不渲染、父容器高度塌陷、flex/grid 子项错位。这不是“偶尔失效”，而是触发了渲染管线的未定义行为。
- iOS Safari ≤ 15.4：
contain: strict会让position: sticky失效，transform元素偏移量归零 - Android WebView ≤ Chrome 89：对
contain: content的子树重绘逻辑错误，常表现为图片/文字突然消失再闪现 - 所有版本 UC 浏览器、QQ 浏览器 X5 内核：直接忽略
contain声明，但不会报错，容易误判为“生效了”
如何检测并安全降级
不能依赖 @supports (contain: layout)，因为旧 Safari 会虚假返回 true，但实际执行崩溃。必须用运行时特征检测 + UA 特征组合判断。
- 优先检查
window.CSS?.supports?.('contain', 'layout')，再叠加navigator.userAgent中是否含Version/15.4或Chrome/89等明确版本标识 - 降级策略不是“去掉 contain”，而是换用等效但兼容的隔离手段：
will-change: transform可触发独立图层（虽无 layout 隔离，但能避免重绘扩散）；overflow: hidden+min-height: 0可强制创建 BFC，防止外部影响 - 若必须保留 contain 语义（如卡片列表性能优化），只对满足
!isIOS15_4Below && !isWebView89Below的设备启用，并用data-contain="applied"标记已生效节点，便于 DevTools 快速排查
contain 导致布局崩溃的典型表现与定位方法
现象不是报错，而是静默错位：卡片高度为 0、文字被裁掉一半、滚动区域突然变窄。这类问题很难通过审查元素发现，需结合渲染层线索判断。
立即学习“前端免费学习笔记（深入）”；
- 打开 Safari 开发者工具 → Elements 面板 → 选中疑似元素 → 查看右侧 “Computed” 标签页，搜索
contain：若显示contain: layout但元素尺寸异常，基本可断定是引擎 bug - 在控制台执行
getComputedStyle(document.querySelector('.card')).contain，返回空字符串或none表示被忽略；返回值正确但布局崩了，就是底层实现缺陷 - 临时注释掉
contain相关声明，刷新页面：若布局立刻恢复，且其他样式无变化，即可锁定问题源
真正麻烦的不是 detect 不到，而是旧版 WebView 里 contain 的行为不可预测——同一段代码，在 iOS 15.3 的 Safari 和同系统下微信内置浏览器里表现可能完全不同。与其花时间 patch 渲染差异，不如把 contain 当作“渐进增强开关”，只在确定安全的环境里开启。
