loading="eager" 会令浏览器忽略滚动位置与视口判断，解析到 img 标签且 src/srcset 有效时立即发起请求，不等待 intersectionobserver 或渲染时机。
img loading=eager 是怎么触发加载的
loading="eager" 会让浏览器**忽略滚动位置和可视区判断，立即发起图片请求**。它不等待元素是否进入视口，也不受 IntersectionObserver 控制，只要 HTML 解析到该 <img> 标签、且资源地址（src 或 srcset）有效，就会立刻开始下载。
这和默认行为（loading="auto"）或 loading="lazy" 有本质区别：后两者依赖浏览器内置的懒加载探测逻辑，而 eager 直接跳过这层判断。
什么时候必须用 loading=eager
以下场景建议显式设置 loading="eager"：
- 首屏关键图片（如 banner、logo、核心产品图），避免因解析/渲染时序或 JS 干预导致加载延迟
- 使用了
srcset+sizes但希望强制触发高 DPR 资源加载（部分浏览器在 lazy 模式下可能先加载低分辨率占位） - 服务端已做图片优化（如响应式裁剪、WebP 自动降级），且确定该图一定会被用户看到
- 图片 URL 是动态拼接的（比如通过 JS 设置
src），而你希望在设值后立刻加载，而非等下次滚动帧
loading=eager 的常见误用和坑
看似“主动”就一定好，实际容易引发问题：
- 设了
loading="eager"但src是空字符串或无效路径（如src=""或src="undefined"），浏览器仍会发一个 404 请求，增加无谓网络开销 - 在 SSR 页面中，若服务端未正确输出
src（比如留空或占位符），客户端 hydration 后才补上，此时eager不起作用——因为加载只在初始 HTML 解析时触发一次 - 与 CSS
display: none或visibility: hidden共存时，eager仍会加载，但图片不会渲染，造成资源浪费 - 部分旧版 Safari（loading 属性，
eager会被忽略，回退到默认行为；不能靠它来“强制保底”
和 JS 手动加载的对比
如果已经用 JS 控制图片加载（比如监听 IntersectionObserver 或点击展开），再设 loading="eager" 就会产生冲突：
-
loading="eager"在 HTML 解析阶段就发请求，JS 还没执行，可能导致重复加载（尤其当 JS 也调用了img.src = ...） - 想实现“点击才加载高清图”，却写了
loading="eager" src="low-res.jpg" srcset="high-res.jpg 2x"，浏览器很可能直接加载high-res.jpg，绕过你的 JS 逻辑 - 真正需要精细控制时，不如移除
loading属性，完全交由 JS 管理：img.loading = "lazy"不生效，但img.src = url是可靠触发点
浏览器对 loading 的实现是声明式、不可中断的，一旦解析就定下来了——这点比 JS 动态控制更“刚性”，也更难调试。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
