loading="lazy"最简单但兼容性有限，仅支持现代浏览器的和；IntersectionObserver更可靠，需合理设置rootMargin和threshold；慎用scroll事件；服务端配合Client-Hints可优化加载内容。
用 loading="lazy" 属性最简单，但兼容性和语义有坑
现代浏览器（Chrome 76+、Firefox 75+、Safari 15.4+）原生支持 loading="lazy"，只需给 加上这个属性即可触发懒加载：
@@##@@
但它只对 和 生效；不支持背景图、srcset 的处理存在
loading="eager"。
IntersectionObserver 是可靠 fallback，但要注意 rootMargin 和阈值
当需要精确控制、兼容老环境，或处理非 元素（如伪元素背景图容器）时，IntersectionObserver 是首选。关键不是“监听是否进入视口”，而是“何时开始加载”：
-
rootMargin: "0px 0px 200px 0px"向下扩展 200px，让图片在用户滚动到它前就触发加载，避免滚动过快时白屏 -
threshold: 0.01表示只要 1% 面积可见即触发，比默认0更早响应（尤其对小图） - 务必在
observer.observe()前，把真实src存在data-src里，而非直接写死在src—— 否则未监听前就已发起请求
const observer = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
const img = entry.target;
img.src = img.dataset.src;
img.classList.remove("lazy");
observer.unobserve(img);
}
});
}, { rootMargin: "0px 0px 200px 0px", threshold: 0.01 });
document.querySelectorAll("img.lazy").forEach(img => observer.observe(img));
慎用 scroll 事件手动实现，性能代价高
用 window.addEventListener("scroll", ...) + getBoundingClientRect() 判断位置，看似可控，实则极易引发性能问题：
- 滚动时高频触发，若每次执行都调用
getBoundingClientRect()，会强制同步布局（layout thrashing） - 没有节流时，Chrome DevTools 的 Rendering 面板常显示大量 “Layout” 黄条
- 移动端 touchmove 更敏感，卡顿更明显
- 无法感知
position: fixed容器内的滚动，或 iframe 内部滚动
除非你明确知道滚动容器是某个 overflow: auto 的 div 且必须兼容 IE11，否则不要走这条路。
服务端配合：用 Accept: image/webp + client-hints 减少无效加载
懒加载只是推迟请求，不代表能省带宽。如果用户网络差、设备像素比高，却仍加载了 2x 大图，意义不大。这时需服务端参与：
- 开启
Client-Hints（如Sec-CH-DPR,Sec-CH-Width），让服务器返回适配尺寸的图 - 利用
Accept请求头判断是否支持webp，后端动态替换src后缀（例如把.jpg改成.webp） - CDN 层配置基于 User-Agent 的降级策略：iOS 14 以下不发 AVIF，Android 10 以下禁用
image/avif
这些和懒加载不冲突，但单独做懒加载，相当于只系了安全带，没关油门。
真正难的不是“怎么让图片晚点加载”，而是“怎么确保它在该出现的时候刚好加载完，且加载的是对的图”。很多项目卡在 IntersectionObserver 的 rootMargin 设多少、threshold 取 0.01 还是 0.1、以及服务端能否及时响应 Client-Hints —— 这些细节才决定懒加载是提升体验，还是制造新的抖动。
