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 的元素，默认按高度 0px 计算布局。它跳过了 layout/paint，但滚动容器总高度仍要靠这个“占位尺寸”来维持稳定。
- 没设
contain-intrinsic-size→ 滚动条突然变短、内容上跳、手指定位错乱 - 写了
contain-intrinsic-size: auto或留空 → 等同于没写，Chrome 和 Safari 都不认 - 写了
contain-intrinsic-size: 0→ 布局彻底塌掉，跟没设一样危险 - 子元素有
height或min-height→ 不会覆盖contain-intrinsic-size，后者优先级更高
contain-intrinsic-size 怎么取值才靠谱
目标不是精确，而是“宁大勿小”：留点余量比留白更安全，尤其对含多行文字或动态展开的卡片。
- 固定高列表项（如每行 64px）→
contain-intrinsic-size: 64px - 固定宽高比卡片（Chrome 122+）→
contain-intrinsic-size: 300px / 200px - 高度不均（比如标题行数不定）→ 取所有可能高度的最小值 × 1.2，例如最小 120px → 写
144px - 富文本/异步加载内容 → 初始设保守值，JS 加载完后用
element.style.containIntrinsicSize = '300px'动态更新
哪些地方不能直接套 content-visibility: auto
它不是 display 替代品，语义和行为都不同，乱用反而破坏体验。
- 需要实时读取
getBoundingClientRect()的场景 → 返回全是0，得等渲染完成再查（可用IntersectionObserver监听进入后再取） - 依赖子元素撑开父容器高度的布局 → 父元素若没显式高度，会因子项未渲染而塌缩
- 用
display: none控制显隐的 JS 逻辑 → 切换时会清空content-visibility缓存，导致重复 layout/paint - 屏幕阅读器关键路径内容（如导航栏、表单主控区）→ 虽然
auto保留可访问性，但若首屏必须朗读，慎加
移动端长列表怎么安全启用
iOS Safari（≥15.4）、Chrome for Android 都支持，但 Firefox Android 和旧版 Safari（≤16.4）不支持，必须降级。
- 用
@supports (content-visibility: auto)包裹样式，避免不支持浏览器误解析 - 不要在
:hover或动画中动态开关content-visibility，触发不稳定 - 下拉加载更多后，新插入的 DOM 节点需立即加上 class 并确保
contain-intrinsic-size已生效 - 测试时重点看快速滚动是否“抽搐”，以及首屏三个卡片是否正常渲染（
auto对紧贴视口顶部的元素有时延迟略高）
最常被忽略的一点：它只跳过渲染，不减少 DOM 节点数、不取消网络请求、不替代图片懒加载——性能瓶颈在哪儿，就得配什么手段，别指望一行 CSS 解决所有问题。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
