content-visibility 不等于图片懒加载，它仅跳过不可见区域的渲染（布局/绘制），但不阻止图片请求；src 一旦设置，下载即触发，与是否可见无关。
content-visibility 本身不负责图片懒加载，它只控制元素是否渲染其内容；想靠它“实现懒加载样式”是方向性错误——它不会触发图片请求，也不影响 src 或 data-src 的行为。
为什么 content-visibility 不等于图片懒加载
它只是让浏览器跳过不可见区域元素的布局、绘制甚至 JS 执行（取决于 contain-intrinsic-size 等配合），但前提是：该元素已经存在于 DOM 中，且其子元素（比如 <img>）的 src 已经被设置。一旦 src 存在，图片请求在元素挂载时就可能已发出，和是否可见无关。
常见误用场景：
- 给包含
<img src="real.jpg">的容器设content-visibility: auto—— 图片早已开始下载，只是渲染被跳过 - 期望它替代
IntersectionObserver或loading="lazy"—— 它不监听视口，也不提供回调 - 没配
contain-intrinsic-size就直接上auto—— 导致滚动时严重布局抖动（CLS）
content-visibility 能配合懒加载做什么
它真正起作用的地方，是「长列表中已加载但尚未进入视口的图片容器」的渲染性能优化，属于懒加载完成后的第二层节流。
适用前提：
- 图片已完成懒加载（
src已写入），DOM 已存在 - 容器高度可预测（必须设
contain-intrinsic-size，否则会塌陷） - 目标是降低滚动帧率压力，而非节省带宽或延迟请求
典型写法：
.list-item {
content-visibility: auto;
contain-intrinsic-size: 200px; /* 必须显式声明，否则 layout shift */
}
注意：contain-intrinsic-size 值要接近真实内容高度，不能写 0 或随意估；移动端 Safari 对该组合支持仍不稳定（2026 年 5 月实测部分机型有重绘延迟）。
真正管用的响应式图片懒加载样式链
响应式 + 懒加载 + 骨架屏不是单点技术，而是一条样式协作链：
- 用
loading="lazy"作为基础层（现代浏览器默认生效） - 用
IntersectionObserver监听并切换data-src → src，同时加opacity: 0 → 1过渡 - 骨架屏必须用
<div> 容器 + <code>::before+ 内联 SVG，不能依赖<img>自身样式 - 所有图片容器必须设
aspect-ratio和width/height，否则加载后必然跳动
最容易被忽略的细节：移动端 Safari 对 will-change: opacity 仍有偶发卡顿，过渡动画里别加它；prefers-reduced-motion 查询必须参与判断，否则动画在系统关闭动画时仍强制执行。
