必须用@supports包裹content-visibility: auto并配合降级占位策略，否则会导致滚动跳变；Firefox至今不支持contain-intrinsic-size，iOS Safari≤16.4完全不支持content-visibility，不能等待普及。
不配 contain-intrinsic-size 的 content-visibility: auto 会直接导致滚动跳变，这不是“兼容问题”，而是功能失效——必须用降级策略绕过，而非等待浏览器普及。
为什么不能等容器查询普及再用 intrinsic-size
contain-intrinsic-size 和容器查询（@container）是两条独立演进的路径：前者依赖 content-visibility: auto 或 contain: size/layout，后者依赖 container-type。它们在 Chrome 107+、Safari 17.4+ 已分别支持，但 Firefox 至今（v128）仍不支持 contain-intrinsic-size，且 iOS Safari ≤ 16.4 完全不支持 content-visibility。指望“等普及”等于放弃当前 20%+ 用户的滚动稳定性。
@supports 是必须写的包裹层，不是可选装饰
直接写 content-visibility: auto 会让旧浏览器解析失败并丢弃整条规则（包括后续声明），所以必须用 @supports 隔离：
/* 必须这样写 */
@supports (content-visibility: auto) {
.list-item {
content-visibility: auto;
contain-intrinsic-size: 160px; /* 固定高度项用单值，卡片用双值如 300px 240px */
}
}
/* 不支持的环境自动 fallback 到普通渲染 */-
@supports检测的是content-visibility: auto，不是contain-intrinsic-size——后者只要前者生效就强制配套，无需单独检测 - 别写
@supports (contain-intrinsic-size: 100px)，这个检测永远返回true却无法反映真实渲染效果 - 服务端渲染时，可通过 UA 字符串注入降级 class（如
.no-cv），避免客户端 JS 重复判断
降级方案要守住两个底线：滚动条不跳、父容器不塌
当 @supports 不成立时，不能只回退到“没优化”，而要模拟 contain-intrinsic-size 的核心作用：占位。
立即学习“前端免费学习笔记（深入）”；
- 对固定高列表项：用
min-height: 160px+height: auto替代，确保父容器有最小高度支撑 - 对卡片类元素：用
aspect-ratio: 3 / 2+width: 100%模拟双值占位，比单纯min-height更稳 - 绝对避免
height: 0或display: none—— 这会让父容器高度塌陷，比不优化更糟 - 图片内部仍需
width/heightHTML 属性，否则降级后懒加载抖动照旧
真正容易被忽略的点
很多人花时间调 contain-intrinsic-size 的精确值，却忘了：它的存在本身就是为了“宁大勿小”。预估偏差 15% 比强行精确但触发 JS 动态重设更可靠——因为每次重设都可能造成 layout shift。兼容方案的核心不是复刻新特性，而是守住“占位不塌”这一条底线。
