content-visibility: auto 能显著提升移动端长列表性能，但必须配合 contain-intrinsic-size 防止滚动跳动；它跳过离屏渲染、保留占位与无障碍支持，而 display: none 会破坏其缓存机制。
移动端长列表卡顿，直接加 content-visibility: auto 就能显著改善，但不配 contain-intrinsic-size 会导致滚动条跳动、页面高度塌陷，实际体验反而更差。
为什么 content-visibility: auto 在移动端特别有用
移动端屏幕小，视口内通常只能显示 3–5 个列表项，但页面 DOM 可能有几百甚至上千个。浏览器默认会为所有项执行 layout + paint，哪怕它们完全在屏幕外。而 content-visibility: auto 让浏览器跳过这些离屏项的渲染，只保留 DOM 占位——实测在 iOS Safari（已支持）或 Chrome for Android 上，1000 条列表的首屏渲染时间可从 800ms 降至 200ms 左右，内存占用下降超 70%。
注意：Firefox Android 和旧版 Safari（iOS ≤ 16.4）仍不支持该属性，需用 @supports 做降级。
必须配 contain-intrinsic-size，否则滚动会“抽搐”
未渲染的元素高度是 0px，浏览器按 0 高度计算滚动区域总高度，等它滚入视口才渲染并撑开真实高度——结果就是滚动条突然变短、内容上跳、用户手指位置错乱。
立即学习“前端免费学习笔记（深入）”；
解决方法很简单：
-
contain-intrinsic-size值应尽量接近单个列表项的真实高度（比如卡片固定高 120px，就写120px） - 若高度不固定（如含多行文字），取保守估计值（如
160px），宁大勿小 - 不能依赖子元素的
height或min-height，contain-intrinsic-size优先级更高 - 避免写成
contain-intrinsic-size: 0或留空，这等于没设
content-visibility: auto 和 display: none 别混用
两者语义和行为完全不同：
-
display: none移除布局空间，屏幕阅读器不可读，JSgetBoundingClientRect()返回全 0 -
content-visibility: auto保留占位、可聚焦、可被查找、无障碍友好，且滚动进入后自动恢复渲染 - 如果在 JS 中动态控制显隐（比如下拉加载更多后手动 show/hide），别用
display切换——这会破坏content-visibility的缓存机制，导致重复 layout/paint - 需要手动触发重绘时（如内容更新后），临时加个 class 再移除更安全：
element.classList.add('force-update'); setTimeout(() => element.classList.remove('force-update'), 1)
移动端适配还要注意这些细节
不是所有容器都“听话”：
- Flex 容器里的子项若设
content-visibility: auto，父容器需加align-items: flex-start，否则可能因基线对齐出错 - Grid 容器中，建议对 grid item 单独设
contain-intrinsic-size，不要依赖grid-template-rows - 慎用于
position: sticky元素——部分安卓 WebView 会忽略其粘性行为 - 滚动监听类库（如 IntersectionObserver）仍可正常工作，但首次回调可能延迟几十毫秒（因渲染滞后）
真正容易被忽略的点是：这个优化只对“静态结构”最有效。如果列表项里嵌了大量 Web Components、频繁触发 requestAnimationFrame 或第三方广告脚本，content-visibility 的收益会大幅缩水——得先清理这些干扰项，再加 CSS 属性。
