content-visibility: auto 配合 contain-intrinsic-size 可显著提升长列表性能，尤其在移动端；未设后者会导致滚动跳动，需注意兼容性、父容器布局限制及高度估算精度。
content-visibility: auto 能直接跳过离屏项的 layout 和 paint，但不配 contain-intrinsic-size 会导致滚动跳动、高度塌陷，实际体验更差。
为什么 content-visibility: auto 在移动端特别有效
移动端视口小，通常只显示 3–5 个列表项，但 DOM 可能有上千个。浏览器默认仍为所有项执行完整渲染流水线。而 content-visibility: auto 让它“装瞎”：保留 DOM 结构和占位，跳过离屏项的样式计算、布局、绘制——实测在 iOS Safari（16.4+）或 Chrome for Android 上，1000 条列表首屏渲染时间可从 800ms 降至 200ms，内存下降超 70%。
注意：content-visibility 在 Firefox Android 和 iOS ≤ 16.4 中不支持，必须用 @supports (content-visibility: auto) 包裹并提供降级方案（比如 fallback 为 opacity: 0.99 或简单 visibility: hidden）。
必须设 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移除布局空间，屏幕阅读器不可读，getBoundingClientRect()返回全 0 -
content-visibility: auto保留占位、可聚焦、可被查找、无障碍友好，且滚动进入后自动恢复渲染 - 若在 JS 中动态控制显隐（如下拉加载后手动 show/hide），别用
display切换——这会破坏缓存机制，导致重复 layout/paint - 需要手动触发重绘时（如内容更新后），临时加 class 再移除更安全：
element.classList.add('force-update'); setTimeout(() => element.classList.remove('force-update'), 1)
Flex/Grid 容器里容易踩的坑
不是所有父容器都“听话”：
- Flex 容器中，子项设
content-visibility: auto时，父容器需加align-items: flex-start，否则可能因基线对齐出错 - Grid 容器中，建议对 grid item 单独设
contain-intrinsic-size，不要指望父容器统一撑开 - 避免在
position: sticky元素或transform父级下使用，containment 可能被截断或失效
真正难处理的是高度估算不准 + 滚动惯性叠加，这时候哪怕 CSS 写对了，用户快速滑动时仍可能看到短暂空白或错位——得靠 IntersectionObserver 提前触发预渲染，或者干脆切到虚拟滚动。
