懒加载核心是按需触发资源加载，推荐用IntersectionObserver替代scroll监听，配合loading="lazy"实现渐进增强，组件懒加载需结合代码分割与视口观察，且必须处理失败fallback。
懒加载不是加个 loading 动画就叫懒加载，核心是「按需触发资源加载」——图片、组件、模块，只要没进入视口或没被调用，就不该发起请求或执行初始化。
IntersectionObserver 是现代懒加载的首选方案
它比监听 scroll 事件更轻量、更精准，浏览器原生支持，且能自动处理节流、相交阈值、根容器偏移等细节。不推荐手动实现 getBoundingClientRect() + scroll 组合，容易卡顿、漏判、兼容性差。
使用时注意：
-
root默认是浏览器视口；若懒加载在滚动容器（如div）内，需显式传入该容器节点 -
threshold设为[0, 0.1]比单个0更稳妥，避免因像素级误差导致首次相交未触发 - 观察器实例应复用，不要每个元素都新建一个
IntersectionObserver
const observer = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
const img = entry.target;
img.src = img.dataset.src;
observer.unobserve(img); // 加载后停止观察
}
});
}, { threshold: [0, 0.1] });
document.querySelectorAll('img[data-src]').forEach(img => observer.observe(img));
图片懒加载必须配合 loading="lazy" 属性
这是浏览器原生懒加载能力，无需 JS 即可生效，且对 SEO 友好。但它的行为有明确限制：
立即学习“Java免费学习笔记（深入）”；
- 仅对
<img>和<iframe>生效 - 只在标准文档流中起作用（
position: absolute或display: none的元素可能被跳过） - 不支持自定义阈值或回调，纯靠浏览器策略决定何时加载
建议采用「渐进增强」策略：loading="lazy" 作为基础层，JS 的 IntersectionObserver 作为增强层（比如要支持 WebP 切换、错误降级、统计上报）。
React/Vue 组件级懒加载别只依赖 React.lazy 或 defineAsyncComponent
它们解决的是代码分割（code-splitting），不是渲染时机控制。组件即使异步加载完成，仍可能立即挂载并执行副作用（如发请求、初始化 canvas），造成无意义的资源消耗。
真正有效的组件懒加载需要两层控制：
- 用
React.lazy/defineAsyncComponent拆分 chunk - 结合
useEffect+IntersectionObserver（或useInView）延迟内部逻辑执行
例如：一个图表组件，import() 加载完 ECharts 后，仍应等待其进入视口再调用 echarts.init() 和 setOption()。
懒加载失败时的 fallback 容易被忽略
网络中断、CDN 故障、路径错误都会让懒加载资源加载失败。此时若不处理，页面可能出现空白、错位或报错中断后续逻辑。
关键动作：
- 为
<img>设置onerror回调，回退到占位图或文字提示 - 对 JS 动态
import()做try/catch，并提供降级 UI（如「功能暂不可用」按钮） - 避免静默失败 —— 至少记录一次
console.warn或上报监控
性能优化不是“加了懒加载就万事大吉”，而是持续判断“此刻是否真需要这个资源”。很多页面把首屏外的轮播图、底部推荐、隐藏 Tab 里的图表全都设成懒加载，却忘了它们可能永远不被用户点开 —— 那些 unobserve 之后的清理、错误兜底、以及是否值得拆 chunk，才是决定懒加载是否真正生效的关键。
