content-visibility: auto 需配合 contain-intrinsic-size（px单位）和 @supports 降级才能在移动端长列表中安全提速，否则会导致高度塌陷、滚动错乱、白屏等问题。
content-visibility: auto 在移动端长列表上能显著提速首屏，但直接加就翻车——它不自动猜高度，也不管 Flex/Grid 容器的对齐逻辑，更不解决图片请求延迟问题。
为什么只写 content-visibility: auto 会让移动端列表更卡
浏览器对设了 content-visibility: auto 的元素，默认跳过 layout 和 paint，getBoundingClientRect().height 返回 0。1000 条消息项每条真实高 80px，但未渲染时全算成 0，整个容器高度塌陷，滚动条瞬间缩成一条线。用户一滑，内容猛往上跳，手指拖动位置错乱。
这不是“没生效”，而是你漏掉了关键配套：
-
contain-intrinsic-size必须显式声明，且单位只能是px（禁用%、em、rem） - 移动端尤其忌讳照搬 PC 的
120px，需按实际字体大小、行高、内边距重新测算 - 若列表项内部有
position: absolute或transform，会强制触发重绘，抵消收益
contain-intrinsic-size 怎么设才不抖动
这不是估算，是向浏览器做的尺寸占位承诺。写小了，内容撑破占位，触发重排；写大了，滚动条预留空间过大，用户误判可滚动范围。移动端建议按以下方式实测校准：
立即学习“前端免费学习笔记（深入）”；
- 纯文字消息项（含头像 + 单行文本）：从
64px起步（iOS 默认16px字体 × 4 行高 ≈64px） - 带图片或两行以上文本的项：宁大勿小，先试
96px，再用 DevTools 检查是否撑破 - 网格布局（如商品卡片）：必须写宽高，例如
contain-intrinsic-size: 160px 180px - 横向长表格（如日志时间线）：只控宽，高度留空：
contain-intrinsic-size: 800px 0
移动端必须加 @supports 降级
iOS Safari ≤ 16.4、Firefox for Android 等仍不支持 content-visibility。不兜底，上线即白屏或布局崩坏。
正确写法是用 @supports 包裹，并提供视觉无感的降级方案：
@supports (content-visibility: auto) {
.list-item {
content-visibility: auto;
contain-intrinsic-size: 64px;
}
}
@supports not (content-visibility: auto) {
.list-item {
opacity: 0.99; /* 不用 visibility: hidden，保留无障碍和 SEO */
}
}别用 display: none 或 visibility: hidden 降级——前者破坏 DOM 可访问性，后者仍参与布局计算，卡顿照旧。
大图列表里别乱加 content-visibility
content-visibility: auto 对 <img alt="怎么用CSS content-visibility提升移动端长列表首屏渲染速度？" > 标签本身无效：它不阻止图片请求，只跳过渲染。如果那张大图是 LCP 元素，加了反而让 LCP 更差——Network 面板里请求早已发出，但渲染被压到滚动进视口才开始，用户等得更久。
真正该加的地方是「固定高度的离屏容器」，比如：
- 折叠评论区展开前的占位区块（预估高
160px） - 瀑布流第 20 页之后的卡片列表（每张卡片含图，但整体高度可控）
- 非首屏的广告位容器（不含动态尺寸变化）
加之前务必确认：这张图的请求已在 Network 面板里排到了合理位置；否则，优化的是假瓶颈。
