loading="lazy"可直接替代滚动监听，但需满足img/iframe标签、真实src、width/height属性等硬性前提；IntersectionObserver用于X5内核兼容、提前加载、失败重试等场景，二者分层共存而非二选一。
直接用 loading="lazy" 就能替代滚动监听，前提是图片满足基本条件；需要提前加载、失败重试或控制动画节奏时，才该上 IntersectionObserver。两者不是“二选一”，而是分层使用：原生属性打底，JS 方案补缺。
loading="lazy"：零成本生效的硬性前提
它不是加了就懒，浏览器会检查几个关键点，缺一不可：
-
必须写在
<img>或<iframe>标签上，对 CSS 背景图、<picture>内的<source>、JS 动态插入的图片无效 -
必须带真实
src，不能只留data-src；否则请求 404，或占位失败 -
必须声明
width和heightHTML 属性（非 CSS），否则 Safari 等浏览器拒绝懒加载，且引发布局偏移（CLS） -
不能被包裹在
transform、overflow: hidden、visibility: hidden或<iframe>容器里，这些会干扰浏览器判断可视区域 -
首屏关键图要显式写
loading="eager"，避免 Safari 或旧版 Chrome 把 banner 也懒掉导致白屏
什么时候必须换 IntersectionObserver？
原生 lazy 在以下场景会失效或能力不足，此时 JS 方案不是“昂贵”，而是必要：
- 页面跑在微信 X5 内核、iOS Safari 15.3 及更早版本，
loading="lazy"不支持或行为异常 - 需要提前加载——比如滚动前 300px 就触发，而不是原生默认的约 1250px 阈值
- 要加加载失败 fallback：比如
img.naturalWidth === 0时显示占位符或错误提示 - 需配合 LQIP（低质量占位图）、渐进式加载动画，或响应式资源校验（如检查
data-srcset是否匹配当前 DPR） - 目标不是
<img>，而是卡片容器、视频模块、自定义组件等非标准元素
不冲突的共存方式：别重复干活
二者混用容易引发竞态或重复请求，正确做法是明确分工：
-
静态 HTML 图片 → 全部用
loading="lazy"+width/height/decoding="async"，不写任何懒加载 JS -
动态渲染内容（如 React/Vue 列表）→ 用
IntersectionObserver监听data-src，不设loading属性，避免框架过滤或浏览器二次干预 -
已用
loading="lazy"的图片，不要再套一层 JS 懒加载逻辑，否则可能 src 被赋两次，触发两次请求 - 服务端渲染（SSR）页面 → 优先用原生属性，JS 方案要等 hydration 完成才启动，存在首屏闪动风险
一个轻量可靠的 IntersectionObserver 示例
不需要复杂库，几行代码就能覆盖大部分需求：
<img class="js-lazy" alt="">
<script>
const observer = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
const img = entry.target;
img.src = img.dataset.src;
img.classList.remove('js-lazy');
observer.unobserve(img);
}
});
}, { rootMargin: '200px' });
document.querySelectorAll('.js-lazy').forEach(img => observer.observe(img));
</script>
