移动端必须设 contain-intrinsic-size，因其向浏览器承诺固定尺寸以避免 content-visibility: auto 导致滚动条塌陷、内容上跳和拖动错位；需用绝对单位保守设定，禁用相对单位，并配合 flex/grid 容器结构调整与兼容性降级。
直接加 content-visibility: auto 在移动端长列表上，不配 contain-intrinsic-size 或忽略 Flex/Grid 容器行为，大概率会让滚动条猛缩、内容上跳、手指拖动错位——这不是优化，是制造交互灾难。
为什么移动端必须设 contain-intrinsic-size
移动端视口小，1000 条列表里通常只有 3～5 项可见。content-visibility: auto 默认把未渲染项高度算成 0px，滚动容器总高度瞬间塌陷，导致：
- 滚动条长度骤减，用户滑动距离预判失效
- 内容突然上跳（浏览器重算布局后“补高”）
- 手指还在原位置拖，但实际触发的是上方/下方的项
contain-intrinsic-size 是向浏览器做的尺寸承诺，不是估算。值必须保守、固定、用绝对单位：
- 固定高卡片：写
contain-intrinsic-size: 80px（别写0或留空） - 含多行文字或图片的项：写
160px（宁大勿小，小了会撑破占位触发重排） - 横向表格类：可只控宽，如
contain-intrinsic-size: 800px 0 - 禁用
%、em、rem——移动端 DPI 和字体缩放会让这些值失准
content-visibility: auto 在 Flex/Grid 容器里容易失效
Flex 容器默认基线对齐（align-items: baseline），而 content-visibility: auto 的项初始高度为 0，会导致父容器拉伸异常或子项错位；Grid 中若只在父级设占位，子项仍可能塌陷。
- Flex 容器中必须加
align-items: flex-start，避免基线对齐干扰 - Grid 容器建议直接在 grid item 上设
contain-intrinsic-size，别指望父容器统一撑开 - 别在
display: flex或display: grid的直接子项上无脑加content-visibility，先确认结构是否“可隔离”
移动端兼容性与降级必须做
iOS Safari ≤ 16.4、Firefox for Android 等主流旧版本完全不支持 content-visibility。上线前不兜底，等于在部分设备上直接放弃性能优化。
- 必须用
@supports (content-visibility: auto)包裹规则 - 降级方案不能用
display: none（会破坏占位和无障碍），推荐opacity: 0.99或保留原样式 - 不要依赖 JS 动态注入
contain-intrinsic-size——移动端 CSS 解析优先级高，JS 注入有延迟，滚动已错乱
别和 will-change: transform 混用
移动端显存紧张，will-change: transform 写在每个列表项上，等于同时创建几十个 GPU 图层，帧率可能从 60fps 直降到 20fps 以下。
-
will-change只能用于真实承载滚动位移的容器（如.list-container），且必须搭配真实transform变化 - 严禁写
.item { will-change: transform; }这类全局规则 -
content-visibility: auto本身已启用 layout/style/paint containment，不需要额外图层加速
真正难的不是加那两行 CSS，而是把 contain-intrinsic-size 的值估准、把容器 display 类型理清、把降级边界守牢——这三处任一出错，效果就从“首屏提速 4 倍”变成“滚动全程发涩”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
