真正影响 layout 性能的是浏览器是否认为元素可能影响布局结果；display: none 彻底退出渲染树，而 content-visibility: hidden 仍参与 layout 计算，contain: strict 需确定尺寸才生效，intersectionobserver 比 scroll 监听更可靠。
视窗外元素（offscreen elements）本身不参与绘制，但只要在 DOM 树中且未被 containment 隔离，就会持续参与 layout 计算——这是多数人忽略的“隐性开销”。关键不是“它没显示”，而是“浏览器每次重排都得检查它是否需要重算”。
为什么 display: none 比 content-visibility: hidden 更省 layout 资源
display: none 会让元素彻底退出渲染树，浏览器连它的盒模型都不构建，自然跳过所有 layout、paint、composite 流程；而 content-visibility: hidden 仍保留在渲染树中，只是跳过 paint，但 layout 和 style 计算照常进行——尤其当它有 width、margin 或参与 flex/grid 分配时，依然会拖慢父容器重排。
- 常见误用：
content-visibility: hidden加在长列表项上，却没配contain-intrinsic-size，结果滚动时频繁触发 layout + paint 回退，比不用还卡 - 真实收益场景：只对高度可预测、且父容器已启用
contain: layout paint的区块使用content-visibility: auto - 若目标是纯 layout 减负，优先用
display: none或直接从 DOM 移除节点（如用DocumentFragment管理虚拟列表）
contain: layout 对 offscreen 元素的隔离效果有限
contain: layout 只能切断该元素内部的 layout 影响范围，但它无法阻止浏览器为该元素自身做 layout 计算——只要它还在文档流中，它的 offsetTop、getBoundingClientRect()、甚至 flex-basis 都会被实时求值。真正起效的是 contain: strict，但前提是容器必须有确定尺寸（height 或 min-height 不为 auto）。
- 失效典型：
.item { contain: layout; }→ 白加，因为没尺寸约束，浏览器静默忽略 - 生效底线：
.viewport { contain: strict; height: 0; overflow: hidden; }+ JS 动态设置height后再 append 子项，才能让子项 layout 完全隔离 - 注意副作用：启用
strict后，其内部position: fixed会退化为absolute，锚点变为该容器左上角
用 IntersectionObserver 触发 layout 卸载比监听 scroll 更可靠
靠 scroll 事件手动切换 display 或 content-visibility 容易漏帧或错判——滚动惯性、触摸回弹、键盘焦点移动都会导致元素短暂进入视口后又被判定为 offscreen。而 IntersectionObserver 基于渲染管线回调，精度高、无重绘抖动，且支持 rootMargin 提前加载。
- 安全阈值建议：
rootMargin: '200px'，确保用户还没滚到就已 layout，避免闪入 - 必须配合状态管理：观察到
isIntersecting === false时，不能立刻设display: none，要等setTimeout(() => {}, 100)防止滚动抖动误判 - 慎用
threshold: [0, 1]：全不可见才触发，但部分遮挡时仍参与 layout；更实用的是[0.01]，只要露 1% 就算“可见”
真正影响 layout 性能的，从来不是“有没有渲染”，而是“浏览器是否认为它可能影响布局结果”。哪怕一个 div 被 transform: translateY(-9999px) 推出屏幕，只要它还在文档流里、没被 contain: strict 或 display: none 切断，它就始终是 layout 计算链上的一环。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
