必须配 contain-intrinsic-size，否则 content-visibility: auto 会导致滚动条抽搐、页面高度塌陷；因其跳过离屏元素的 layout 和 paint，使 clientheight 返回 0，滚动容器高度突变，引发布局抖动。
直接加 content-visibility: auto 不行，必须配 contain-intrinsic-size，否则滚动条抽搐、页面高度塌陷，性能反而更差。
为什么 content-visibility: auto 会跳过重绘但引发布局抖动
它让浏览器对离屏元素跳过 layout + paint，自然就减少了盒模型计算和重绘开销。但代价是：未渲染元素的 clientHeight、getBoundingClientRect() 都返回 0，整个滚动容器高度被算成“一堆 0”，导致滚动区域突变。用户一滑，内容上跳、滚动条缩回、手指位置错乱——这不是优化，是反效果。
关键点在于：content-visibility: auto 默认启用 size containment，相当于把元素当空盒子处理；没 contain-intrinsic-size，就是真·空盒子。
- 不写
contain-intrinsic-size或写成0，等于没设 - 值不是“估算”，而是“占位承诺”：浏览器按这个尺寸预留空间，不能靠子元素 height 推导
- 高度不固定时（如含多行文本），宁可估大（如
160px），别估小——小了会撑破占位，触发重排
contain-intrinsic-size 怎么设才不翻车
它只接受具体数值或 auto（部分浏览器支持有限），不接受百分比、em、rem 等相对单位。移动端常见错误是照搬 PC 端写法，或者依赖 JS 动态注入，结果首屏就抖。
- 卡片类列表（固定高）：直接写死，如
contain-intrinsic-size: 120px - 文字流式项（高度浮动）：取最大可能高度保守值，如
contain-intrinsic-size: 240px - 宽高都需控制时（如网格项）：用双值语法
contain-intrinsic-size: 300px 240px - 子元素有显式
height？它会被忽略——contain-intrinsic-size优先级更高
和 display: none 混用会破坏缓存机制
如果你在 JS 中做“显示/隐藏”切换（比如点击展开某区块），千万别用 display: none/block 去控制已设 content-visibility: auto 的元素。这会让浏览器丢弃已缓存的渲染状态，下次再进视口就得重新 layout + paint，白费功夫。
- 正确做法：用 class 控制显隐逻辑，例如临时加
force-update触发重绘 - 需要强制刷新内容时（如富文本加载完成），可
element.classList.add('force-update')，再setTimeout(() => element.classList.remove('force-update'), 1) -
content-visibility: hidden虽能缓存，但读屏器不可读、tabindex失效，生产环境慎用
兼容性与移动端特殊约束
Chrome 85+、Edge 85+、Safari 15.4+（iOS ≥ 16.4）已支持，但 Firefox（含 Android 版）至今无计划支持。上线前必须用 @supports (content-visibility: auto) 包裹，或 UA 判断降级。
移动端还有两个易忽略细节：
- Flex 容器中，子项设
content-visibility: auto时，父容器最好加align-items: flex-start，否则基线对齐可能错位 - Grid 布局中，
contain-intrinsic-size必须设在 grid item 上，不能只设在 container 上 - 表单控件、焦点元素若被延迟渲染，键盘 Tab 导航可能中断，需额外测试
最麻烦的从来不是加哪两行 CSS，而是预估那个“占位高度”——它得稳，不能随内容变，又不能太离谱。一旦动态内容（如收起/展开、图片加载）改变了真实高度，就必须用 JS 更新 contain-intrinsic-size，否则后续所有滚动行为都会失准。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
