content-visibility: auto 必须配合 contain-intrinsic-size 使用，否则浏览器按高度0处理导致滚动条跳变、内容闪入、页面塌陷；该值需设为具体像素且“宁大勿小”，不可为空、auto或0。
浏览器如何基于HTML层级做渲染分块
现代浏览器（Chrome/Edge/Firefox）的渲染引擎不会等整个DOM树建完才开始绘制，而是边解析HTML边构建布局树、生成图层、分块光栅化。但这个“分块”不是按DOM嵌套深度平均切的，而是受 contain、transform、opacity 等CSS触发的层叠上下文（stacking context）和独立渲染上下文（paint containment）影响更大。单纯增加 <div> 嵌套层数，只要没触发新的图层或重排边界，对分块粒度几乎无影响。
<p>真正拖慢分块效率的是：过深的、带样式计算依赖的嵌套（比如每层都用 <code>calc() 或 em 单位），或在滚动容器内存在大量未被 contain: paint 隔离的兄弟节点——此时浏览器无法安全地复用已光栅化的图块，被迫频繁重绘整块区域。
contain: strict 为什么比多套 <div> 更有效
<p>一个常见误区是用一堆空 <code><div> 包裹内容来“结构化”，以为能帮浏览器识别区块。实际上，没有 <code>contain 的包裹只是增加样式继承链和布局树节点数，反而抬高首次渲染开销。而 contain: strict 显式告诉引擎：“这个子树的布局、样式、绘制、尺寸都不影响外部，也不受外部影响”。浏览器就能：
- 跳过该子树的样式计算传播（除非内部有
:hover 等动态伪类）
- 把它的布局结果缓存为独立单元，滚动时直接复用图块
- 避免因父级
width 变动触发整个子树重排
:hover 等动态伪类）width 变动触发整个子树重排示例：
<div class="card" style="contain: strict"> <h3>标题</h3> <p>正文...</p> </div>比
<div><div><div><div>...</div></div></div></div> 在长列表中滚动帧率提升更明显。
哪些嵌套模式会意外阻断分块优化
即使没写 contain，某些CSS组合也会隐式创建隔离边界，但效果不如预期，甚至起反作用：
-
position: absolute+top/left值依赖父级尺寸 → 浏览器仍需保留父级布局信息，无法安全分块 - 使用
will-change: transform但没实际动画 → 提前升层，增加图层管理开销，且可能阻止合并相邻图块 - 在
overflow: scroll容器里嵌套display: grid，又没设grid-template-rows固定行高 → 滚动时每帧都要重新测量所有行，无法复用光栅块
这类情况不会报错，但 Chrome DevTools 的 Layers 面板里能看到大量细碎、不可复用的小图层，Rendering 开启后会高频闪烁。
用 content-visibility: auto 替代手动分层的适用边界
content-visibility: auto 是目前最接近“自动分块”的方案，但它只对离屏元素生效，且要求元素有明确高度（否则无法预估可见区域）。它不替代 contain，而是补充：
- 当元素在视口外，且满足
height或contain-intrinsic-size时，整个子树会被跳过布局和绘制 - 一旦滚动进入视口，才触发完整渲染 —— 这个“懒加载”过程本身有微小延迟，不适合动画频繁或交互密集的区域
- 不能和
transform动画共存（会强制解除隔离），也不能用于position: fixed元素
所以它适合长文章段落、评论列表这种静态内容区块，而不是导航栏或实时图表。
复杂点在于：contain 和 content-visibility 都依赖开发者对内容生命周期的预判。一个没设 contain-intrinsic-size 的 content-visibility: auto 容器，反而会让浏览器反复重排，比不用还慢。
