loading=eager是img原生属性，指示浏览器立即加载图像，适用于首屏关键图、LCP元素等；需配合width/height或aspect-ratio使用以防CLS，Chrome76+等现代浏览器支持，SSR中需防框架自动覆盖。
img loading=eager 是什么，什么时候该用
loading=eager 是 <img> 的原生属性值，告诉浏览器“立刻加载这张图，不要懒加载”。它和默认行为（loading=lazy）相反，适用于**页面首屏关键内容、LCP 元素、或必须同步渲染的图像**。不是所有图都适合设为 eager —— 比如瀑布流里第二屏的图加了它，反而会拖慢首屏解析和资源竞争。
哪些图必须设 loading=eager
以下情况不设 eager，容易触发 CLS（布局偏移）或拉低 LCP 分数：
- 首屏 banner 图、主标题旁的 logo、产品主图（LCP 候选元素）
- 用 CSS
background-image模拟但实际靠<img>实现的关键视觉块（比如 hero section 中的<img>） - 没有宽高属性（
width/height）且未提前预留容器尺寸的图——此时 eager 能减少重排，但更治本的是补上尺寸
loading=eager 和 width/height 一起用才真正稳定
只写 loading=eager 不解决布局抖动。浏览器仍可能在图片加载前按 0×0 渲染，导致文字上推。真正起效需配合显式尺寸：
<img src="hero.jpg"
width="1200" height="600"
loading="eager"
alt="首页主图">
注意：width 和 height 应是原始图的**固有尺寸比**（如 1200×600），而非 CSS 缩放后的值；否则可能拉伸或模糊。现代做法倾向用 aspect-ratio + object-fit 替代固定宽高，但 loading=eager 仍需保留。
立即学习“前端免费学习笔记（深入）”；
兼容性和 SSR 场景下的坑
loading=eager 在 Chrome 76+、Firefox 75+、Safari 15.4+ 支持，IE 完全不支持（忽略该属性，回退到默认加载）。服务端渲染（SSR）时尤其要注意：
- Next.js / Nuxt 等框架若开启自动
loading=lazy注入，需显式覆盖：加loading="eager"并确保不被 HOC 或 Image 组件二次包裹改写 - 使用
<picture>时，loading必须写在<img>上，<source>不支持该属性 - Webpack/Vite 构建时若启用了图片内联（url-loader/data-uri），
loading属性仍有效，但 base64 图本身无加载延迟，eager变成冗余——可省略
最关键的不是加不加 eager，而是判断这张图是否真的参与首次绘制且无法异步——很多所谓“关键图”，其实只是设计师觉得重要，但性能工具里压根没进 LCP 候选列表。
