前端大列表为什么滚动会抖：content-visibility 与占位高度的取舍

商品后台把每页 200 条改成连续长列表后，首屏确实快了，但鼠标滚到中段时滚动条会突然变长，列表像被轻轻拽了一下。很多时候，问题不是虚拟列表失效，而是给屏外内容加了 content-visibility: auto，却没有给浏览器一个可信的占位高度。

长列表变快后，滚动条为什么反而不稳

浏览器要计算页面总高度，不能只看当前视口。使用 content-visibility: auto 后，屏外项可以暂时跳过内容渲染；如果这些项没有正常的尺寸信息，布局阶段只能按“内容还没展开”的状态估算。

假设每张商品卡片平均高度约为 176px，却没有设置占位高度。首屏之外的卡片可能先按很小的尺寸参与布局，滚动到它们附近后，真实图片、价格和促销信息被渲染出来，页面总高度随之增加，滚动条就会发生可见变化。

先用最小 CSS 让每张卡片有稳定占位

把列表项切成独立的块，再给出一个接近真实平均值的高度。这里的数字不是性能常数，而是你的卡片在图片加载完成后的合理估计。

.product-card {
  content-visibility: auto;
  contain-intrinsic-size: auto 176px;
}

content-visibility: auto 让屏幕外卡片可以跳过绘制；contain-intrinsic-size 给布局一个 176px 的高度参考。使用 auto 176px 时，卡片被正常渲染后，浏览器可以记住已经得到的尺寸，后续离开视口时优先使用记忆值。

先不要把这个值写成 1000px 来“压住抖动”。占位高度过大会让用户拖动滚动条时落在空白附近，甚至让分页加载的触发位置失真。

什么时候应该从平均值改成分组估算

如果列表里同时有普通商品卡、带两行标题的卡和带横向促销图的卡，一个平均值很快就会失真。更稳的方式是按真实布局分组，让 CSS class 表达尺寸差异：

.product-card {
  content-visibility: auto;
  contain-intrinsic-size: auto 176px;
}

.product-card--featured {
  contain-intrinsic-size: auto 248px;
}

分组不是越细越好。只有当卡片的结构确实不同、并且差异会积累到滚动条上时，才值得增加一个尺寸档位。否则维护多个估值，比一次轻微的布局修正更容易出错。

把性能收益和可见状态放在同一套验收里

这类优化不能只看首屏耗时。打开浏览器性能面板，分别测试首次加载、快速拖到列表中段、滚回顶部和图片慢加载四个动作；同时记录滚动条长度是否突然改变，以及当前卡片是否出现空白占位。

如果滚动条仍然跳，先检查图片是否有宽高属性、字体加载是否改变标题换行，再调 contain-intrinsic-size。占位高度只能解决尺寸未知，不能替图片和字体造成的二次布局背锅。

三种场景下的取舍

卡片高度接近固定

优先使用 content-visibility: auto 加 contain-intrinsic-size: auto 176px。估值容易建立，收益也比较稳定。

卡片高度差异明显

先按结构分成两到三个尺寸档位。若内容仍然持续追加，虚拟列表通常比继续堆 CSS 估值更合适。

内容高度由异步数据决定

给图片、视频和可展开区域预留尺寸，并在数据完成后观察是否触发大范围布局变化。不要把 content-visibility 当成异步布局的替代品。

常见问题

content-visibility: auto 会自动保持真实高度吗？

它允许浏览器跳过屏外内容的渲染；是否稳定还取决于元素的尺寸约束。配合 contain-intrinsic-size: auto ...，已渲染过的尺寸可以被记住，但第一次估算仍需要合理。

占位高度应该用最大卡片高度吗？

通常不应该。最大值会制造大片虚空，拖动滚动条时体验更差。用样本测出的中位或分组平均值，再为明显更高的卡片单独设档位更实际。

有了 content-visibility 还需要虚拟列表吗？

需要时仍然需要。content-visibility 主要减少屏外渲染成本，虚拟列表还会减少 DOM 数量和事件管理成本；数据量、交互复杂度和卡片高度差异决定最终选择。

小结

长列表的滚动抖动，本质是“渲染被延后了，但尺寸没有被提前说明”。先用 content-visibility: auto 缩小屏外工作量，再用接近真实布局的 contain-intrinsic-size 稳住占位高度，最后用滚动条、图片加载和异步展开场景复查。卡片差异已经大到无法估算时，就把问题交给分组或虚拟列表处理。