原生 loading="lazy" 无法实现响应式图片延迟加载，因其只检测视口进入而不感知设备宽度、dpr 或 srcset 切换；必须用 intersectionobserver 手动结合 data-srcset、sizes 和设备上下文控制加载时机与源图选择。
原生 loading="lazy" 无法真正实现“响应式图片延迟加载”——它只管是否进视口，不管设备宽度、DPR 或 srcset 切换时机。真要兼顾响应式与懒加载，必须用 IntersectionObserver 手动控制 src 和 srcset 注入。
为什么 loading="lazy" 在响应式画廊里基本失效
浏览器对 loading="lazy" 的实现是静态的：它在首次 layout 后按固定阈值（约 1250px 下方）预取，但完全不感知视口缩放、设备像素比变化或 CSS 布局重排。结果就是：
- 小屏手机滚动时，仍可能加载 1200w 大图（
srcset选错源） - 横竖屏切换后，已加载的图片不会自动替换为更适配的尺寸
- 画廊项用
transform: scale()或overflow: hidden包裹时，懒加载直接退化为 eager - 图片在
<table> 或 <code><picture></picture>内部时，Chrome/Safari 支持极弱，属性被忽略必须手动配合
srcset+sizes才能精准选图仅靠 JS 懒加载不够，
srcset和sizes是浏览器在 HTML 解析阶段就决定请求哪张图的关键。漏掉任一环，懒加载就失去意义：-
srcset必须用w描述符（如"small.jpg 480w, medium.jpg 1024w"），不能只写1x/2x -
sizes必须是条件表达式，例如sizes="(max-width: 768px) 100vw, 50vw"；写死成"50vw"或"30rem"会导致 fallback 到 100vw，小屏也下大图 - HTML 中
<img>的width/height或 CSSaspect-ratio必须存在，否则布局抖动不可控
用
IntersectionObserver实现可预测的加载时机这是唯一能同时控制「何时加载」和「加载哪张图」的方案。关键不是监听“是否进入”，而是结合设备上下文做决策：
- 把真实地址存在
data-srcset（格式同原生srcset），占位图用src="data:image/svg+xml,%3Csvg%3E" - 观察器初始化时设
{ threshold: 0.05 }（5% 进入即触发），避免快速滚动漏掉 - 回调中计算当前所需物理像素：
Math.min(window.innerWidth * window.devicePixelRatio, 最大候选宽度) - 从
data-srcset中挑最接近且不小于该值的w图，赋给img.src并同步设img.srcset = img.dataset.srcset - 立即调用
observer.unobserve(img)，否则重复执行
首屏关键图必须绕过懒加载逻辑
Hero 图、Logo、头像这类元素一旦被
IntersectionObserver或loading="lazy"拦截，在 Safari（尤其 iOS 16.3 及更早）上大概率白屏。解决方案非常具体：- 首屏
<img>显式写loading="eager"，不要依赖默认行为 - 同时加
<link rel="preload" as="image" href="hero.webp">，且href必须和img.src完全一致 - 禁止给首屏图再写
data-src或data-srcset，否则 JS 加载逻辑会覆盖 preload - 如果首屏图由框架动态渲染（如 React
map()），需在 SSR 阶段就输出完整src+loading="eager"
真正难的不是写几行 Observer 代码，而是让每张图的
sizes精确反映它在各断点下的实际渲染宽度——这个值藏在 CSS 媒体查询、容器 max-width、flex/gird 分配逻辑里，改一处样式，可能就要重算整套sizes表达式。 -
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
