content-visibility: auto 必须搭配 contain-intrinsic-size，否则浏览器按高度0处理未渲染元素，导致滚动条跳变、内容闪入和页面塌陷；contain-intrinsic-size为其预设占位尺寸以保障布局稳定。
直接加 content-visibility: auto 能显著提速，但不配 contain-intrinsic-size 很可能让滚动条跳、内容闪、页面塌陷——这不是“开了就赢”，而是“开了就踩坑”。
为什么 content-visibility: auto 必须搭配 contain-intrinsic-size
浏览器对 content-visibility: auto 元素默认按高度 0 处理：它跳过布局计算，但滚动容器仍需知道“这块内容本该占多高”。没这个预估尺寸，就会：
- 滚动条突然收缩（内容渲染后高度撑开，滚动范围变大）
- 快速滚动时内容“闪入”（高度从 0 突变，触发重排）
- 页面整体高度塌陷（父容器高度塌为 0，影响其他元素定位）
contain-intrinsic-size 就是给这个“未渲染区域”填一个占位尺寸。它不是真实渲染高度，而是告诉布局引擎：“这里预留这么多空间”。
contain-intrinsic-size 怎么设才不翻车
值必须是具体像素或宽高对，不能留空或写 auto（部分浏览器不支持，等于没设）：
- 单行固定高列表（如菜单项、消息气泡）：
contain-intrinsic-size: 48px - 卡片类（宽高比稳定）：
contain-intrinsic-size: 300px / 200px（Chrome 122+ 支持） - 高度不均？取保守值——比如所有卡片最小高度的 1.2 倍，避免留白过大
- 子元素有显式
height？那个height会覆盖contain-intrinsic-size的高度设定，但宽度不受影响
哪些地方加了反而更卡
content-visibility 不是全局开关，几个典型失效/反效果场景：
-
position: fixed子元素：被隔离后脱离视口定位上下文，直接飘到错误位置 - 用了
ResizeObserver或IntersectionObserver：未渲染区域不会触发回调，得在auto → visible切换后手动补发 - 父容器设了
overflow: hidden且子元素需要溢出展示：content-visibility强制 layout containment，会截断溢出 - 服务端渲染（SSR）页面里直接加：首屏 HTML 已含完整 DOM，但 JS 没跑，用户可能看到空白区块；建议用 hydration 状态控制初始值
content-visibility: hidden 和 display: none 别混用
两者都“看不见”，但底层逻辑完全不同：
-
content-visibility: hidden：DOM 还在，布局空间保留，子元素完全不参与样式计算、布局、绘制；tabindex、focus()、getBoundingClientRect()仍可用，但offsetHeight为 0 -
display: none：DOM 彻底排除出渲染树，不占空间，也不响应任何交互或尺寸查询 - 反复切换时，
content-visibility: hidden ↔ auto比display: none ↔ block更轻量，尤其含大量子节点时 - 慎用于表单控件：
<input>在content-visibility: hidden下仍保留在 tab 顺序中，但无法聚焦——行为不一致
真正容易被忽略的点是：动态内容（如展开/收起、富文本加载）会导致实际高度变化，但 contain-intrinsic-size 不会自动更新——必须用 JS 后续手动设置，否则占位失真。这一步漏掉，性能优化就变成布局 bug 的温床。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
