content-visibility 在 ie 中完全不支持；旧版 safari（≤16.4）和部分 firefox（如 android 版及旧桌面版）也不支持，需用 @supports 或 ua 检测降级。
content-visibility 在 IE、旧版 Safari 和 Firefox（@supports 一劳永逸——它只拦住不支持的浏览器忽略该声明，但无法补救已渲染却错位的 DOM。
哪些浏览器根本没实现？
截至 2026 年 6 月：
- IE 所有版本：零支持
- Safari ≤ 15.3（含 iOS 15.3 及更早）：无
content-visibility，也无contain-intrinsic-size - Firefox content-visibility: auto，但
contain-intrinsic-size直到 125 才稳定，且需手动开启 flag - Chrome 85–121、Edge 85–121：支持
content-visibility: auto，但对contain-intrinsic-size的解析存在高度差异（如 Safari 15.4+ 支持单值，Chrome 122+ 才支持双值300px / 200px）
@supports 不够用，必须配合 UA 检测或构建时剔除
@supports (content-visibility: auto) 只能防止语法报错，但无法解决以下真实问题：
- Firefox 124 用户看到滚动条突然跳变（
contain-intrinsic-size被忽略，高度回退为 0） - Safari 15.3 用户页面 footer 上浮（
content-visibility: auto被静默丢弃，但父容器 overflow/height 计算逻辑已被干扰） - 服务端直出（SSR）场景下，Node.js 渲染时无 UA 上下文，
@supports完全不生效
更稳妥的做法是：
- 构建阶段用 PostCSS 或自定义插件，根据
.browserslistrc自动移除不支持环境下的content-visibility声明 - 运行时用
navigator.userAgent粗筛（例如匹配/Safari\/[\d.]+.*Version\/15\.([0-3]|$)/），再设element.style.contentVisibility = 'visible' - 对 SSR 页面，初始 HTML 中默认写
content-visibility: visible，hydration 后再按能力升级
降级方案不是“加 fallback”，而是重写渲染逻辑
很多人以为加个 display: block 就是降级，其实错得离谱：content-visibility: hidden 保留占位，display: none 彻底移除，两者行为不可互换。
- 真要兼容 IE11 或 Safari 15.3，应改用 IntersectionObserver + 手动 toggle
visibility: hidden+position: absolute占位（模拟contain-intrinsic-size效果） - 对长列表，可用
transform: translateY()移出视口 +pointer-events: none配合，比强行塞content-visibility更可控 - 若必须保留 DOM 密度（如 SEO 或无障碍），降级时应主动注入
height行内样式替代contain-intrinsic-size，例如：el.style.height = '64px'
最易被忽略的一点：即使浏览器支持 content-visibility，如果父元素用了 overflow: hidden 或含 position: fixed 子项，该属性会直接破坏布局——这种 case 在降级逻辑里根本不会触发，但上线后用户就是卡死。务必在真实设备组合（尤其是 iOS Safari + Chrome Android）上验证容器链路。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
