图片资源往往占据页面总体积的一半以上，如果一个商品列表页需要展示上百张图片，浏览器在首次加载时就会同时发起大量网络请求，不仅拖慢首屏速度，还会抢占其他关键资源的带宽。懒加载的思路很简单：只有当图片即将滚动到可视区域内时才真正发起请求，其余时间用占位图或空白容器代替。在React项目里，借助浏览器原生的Intersection Observer API，我们可以用极少的代码实现一套高性能、可复用的懒加载方案。
为什么不再推荐监听scroll事件实现懒加载
早期的懒加载实现几乎都依赖scroll事件加getBoundingClientRect的组合。每次滚动事件触发时，遍历所有待加载图片，调用getBoundingClientRect计算图片相对视口的位置，判断是否进入可见范围。这个方案能工作，但存在几个难以回避的问题。
首先是性能开销。滚动事件触发频率非常高，如果回调中没有做节流处理，主线程会被频繁打断，页面在低端机型上明显卡顿。其次，getBoundingClientRect本身会强制浏览器同步执行布局计算，一旦在回调中又修改了DOM（比如给img标签赋值src），就可能引发反复的布局抖动，也就是常说的强制重排。最后，这种写法还需要额外处理resize、横竖屏切换、动态增删元素等情况，代码复杂度随着边界场景不断增加。
Intersection Observer API正是为了解决这类需求而生。它把可见性检测完全交给浏览器在合成线程中处理，只有当目标元素与根元素的交叉状态发生改变时，才会通过回调通知开发者。React本身要求不要在渲染期间直接操作DOM，这种声明式的观察机制与React的生命周期模型天然契合。
Intersection Observer核心概念速览
使用这个API的核心是IntersectionObserver构造函数，它接收两个参数：一个回调函数和一个配置对象。配置对象包含三个字段。root指定参照的祖先元素，默认为浏览器视口；rootMargin用于扩大或缩小根元素的判定范围，写法与CSS的margin类似，例如'200px 0px'表示在视口四周各扩展200像素的预判区域；threshold定义交叉比例达到多少时触发回调，取值0到1之间，也可以是数组。
const observer = new IntersectionObserver(
(entries, obs) => {
entries.forEach(entry => {
// entry.isIntersecting 为 true 表示目标进入视口
if (entry.isIntersecting) {
const img = entry.target;
img.src = img.dataset.src; // 把真实地址赋给 src
obs.unobserve(img); // 加载一次后停止观察
}
});
},
{
root: null, // null 代表浏览器视口
rootMargin: '200px', // 提前 200px 预加载，减少用户等待感
threshold: 0.1 // 交叉比例达到 10% 时触发
}
);
document.querySelectorAll('img[data-src]').forEach(img => observer.observe(img));回调函数接收一个entries数组，每个entry包含多个有用字段：isIntersecting表示是否可见，intersectionRatio给出当前交叉比例，target指向被观察的DOM节点。一个观察器实例可以同时观察成百上千个元素，浏览器内部会统一调度，比手动监听滚动省心得多。加载完成后调用unobserve非常重要，否则同一张图片会在每次进出视口时重复触发回调。
在React中封装一个useLazyImage自定义Hook
直接在组件里操作DOM不符合React的最佳实践，更好的方式是把观察逻辑封装成自定义Hook，通过ref挂载到img元素上。下面这个Hook返回一个ref和一个加载状态，图片真实地址通过参数传入，进入视口后才赋值，同时配合透明度过渡实现淡入效果。
import { useRef, useState, useEffect } from 'react';
function useLazyImage(src, placeholder) {
const imgRef = useRef(null);
const [loaded, setLoaded] = useState(false);
const [currentSrc, setCurrentSrc] = useState(placeholder);
useEffect(() => {
const node = imgRef.current;
if (!node) return;
// 不支持的环境直接降级加载
if (!('IntersectionObserver' in window)) {
setCurrentSrc(src);
return;
}
const observer = new IntersectionObserver(
(entries, obs) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
setCurrentSrc(src);
obs.unobserve(entry.target);
}
});
},
{ rootMargin: '200px 0px' }
);
observer.observe(node);
return () => observer.disconnect(); // 组件卸载时清理
}, [src]);
return { imgRef, currentSrc, loaded };
}在业务组件中使用时，只需把ref挂到img上，并在onLoad回调里更新状态触发淡入动画。
function ProductCard({ url, alt }) {
const { imgRef, currentSrc, loaded } = useLazyImage(url, 'data:image/gif;base64,R0lGODlhAQABAAAAACw=');
return (
<img
ref={imgRef}
src={currentSrc}
alt={alt}
onLoad={() => setLoaded(true)}
style={{ opacity: loaded ? 1 : 0, transition: 'opacity 0.4s ease' }}
/>
);
}注意useEffect的清理函数中调用了disconnect，这一步不能省略。React组件在列表滚动、路由切换时可能频繁卸载重建，如果不清理观察器，会造成内存泄漏，卸载后的节点依然被浏览器持有引用。另外，当src发生变化时，Hook会重新建立观察，保证切换图片地址时行为正确。
占位图的选择也有讲究。示例中用了一个1像素的透明GIF，它几乎不占体积，但缺点是加载前区域高度塌陷，容易引起布局偏移。更推荐的做法是给img设置固定的宽高或使用aspect-ratio属性锁定比例，再搭配浅灰色背景，这样用户在图片加载完成前看到的是一块稳定的灰色区域，体验明显好于空白跳动。
与第三方库的对比及进阶优化建议
社区里成熟的方案如react-lazyload、react-intersection-observer等封装了更多功能，例如滚动方向记忆、占位组件插槽、服务端渲染兼容。如果项目时间紧、场景复杂，直接用库是合理选择。但自定义Hook的优势在于零额外依赖、体积可控，并且能完全按照业务需求定制，比如在下拉加载更多时给新节点补挂观察器。需要注意，2023年之后的现代浏览器中，img标签已原生支持loading="lazy"属性，一行代码即可实现基础懒加载。
<img src="photo.jpg" alt="商品图" loading="lazy" decoding="async" />
原生属性虽然方便，但它的预加载时机由浏览器控制，无法精细调节，也没有加载动画等交互细节。实践中比较务实的策略是：普通文章配图直接用loading="lazy"，对体验要求高的长列表或瀑布流再用Intersection Observer方案精细打磨。
几个容易踩坑的点值得留意。第一，rootMargin设置过小会导致图片滚到视口边缘时才开始请求，用户会看到明显的加载等待，建议至少预留一到两屏的距离；第二，如果列表使用了虚拟滚动，真实DOM节点会被复用，此时必须在节点复用时更新观察对象，否则会出现图片错位；第三，图片服务端尽量配合输出WebP或AVIF格式，懒加载解决的是请求时机问题，压缩格式解决的才是传输体积问题，两者结合才能把优化效果最大化。
总结一下，Intersection Observer把原来繁琐的滚动计算交给了浏览器底层，配合React的Hook机制可以封装出简洁优雅的懒加载组件。先从自定义Hook入手理解原理，再根据项目规模决定是否引入第三方库，最后结合响应式图片和现代压缩格式，一套完整的图片优化链路就搭建完成了。
Intersection ObserverReact图片懒加载前端性能优化修改时间：2026-09-09 21:37:06