首屏关键图必须显式声明loading="eager"，因其非可选项而是强制保障：省略时浏览器依赖启发式判断，在ssr、旧版safari或爬虫环境下易误判为非关键资源，导致白屏、lcp延迟或重复加载；显式声明才能确保跨环境可靠立即加载。
loading="eager" 不是可选项，而是首屏关键图片的强制加载声明——不写它，浏览器也可能按默认行为加载；但写了，才能确保在所有兼容环境下不被懒加载策略误伤。
为什么首屏图必须显式写 loading="eager"
浏览器对 loading 属性的处理是“非 lazy 即 eager”，但部分旧版或特殊配置下（如 SSR 渲染 + 爬虫环境），未声明该属性的图片可能被启发式策略误判为“非关键”，尤其当图片 URL 含查询参数（image.jpg?v=2）或父容器高度未定导致位置计算偏差时。显式声明 loading="eager" 是唯一能绕过这些不确定性的硬性保障。
- Chrome 100+、Edge 100+ 默认行为确实是 eager，但 Safari 15.4 之前完全忽略
loading属性，此时未声明等同于无约束 - 某些 SSR 框架（如 Next.js 13 App Router 默认 SSR）中，首屏图片若仅依赖默认行为，旧版 Googlebot 可能跳过抓取
- 当页面存在多个
<img>且共享同一资源路径（如 banner 多次复用同一张图），未声明 eager 可能触发重复请求：一次由 lazy 预加载机制提前发起，另一次由渲染引擎 fallback 补发
loading="eager" 和省略该属性的实际区别
表面上没差别，但语义和可控性完全不同。省略时，你把决定权交给浏览器的启发式调度；显式写 loading="eager" 是向渲染引擎发出明确指令，尤其在以下场景差异明显：
- 使用
<picture></picture>+<source></source>时，loading必须写在<img>上，<source></source>上无效；省略易漏写，显式声明则强制聚焦到正确节点 - 配合
fetchpriority="high"使用时，只有两者同时存在才构成完整优先级信号链（loading="eager"+fetchpriority="high"），单独一个效果打折 - 服务端模板中动态插入图片时，逻辑分支若漏掉 eager 声明（比如 fallback 到占位图路径），会导致该图实际变成 lazy 加载，破坏首屏完整性
哪些地方容易漏掉 loading="eager"
不是所有“看起来在首屏”的图都会被自动识别为关键资源。以下情况常被忽略，但必须补上：
- 通过 CSS
background-image加载的 banner 图——loading属性对它完全无效，必须改用<img>标签并加loading="eager" - React/Vue 组件中动态生成的首屏头像：
<img :src="avatarUrl" alt="用户头像">，若没绑定loading属性，SSR 或 hydration 过程中极易降级 - 使用
srcset+sizes的响应式 hero 图，即使尺寸适配再精准，不写loading="eager"仍可能被 Chrome 的 lazy 启发式算法提前拦截（尤其在 4G 网络模拟下） - Gradio 或低代码平台生成的 UI 中，自动生成的缩略图、状态图标，默认不带
loading，需在 wrapper 层手动注入
上线前必须验证的三件事
写了不等于生效。部署后务必检查：
- 打开 Chrome DevTools → Network → 刷新页面 → 查看首屏图片请求的 Priority 列是否为
Highest或High（需勾选 Priority 表头）；若仍是Medium，说明fetchpriority或loading未生效 - 用 Lighthouse 跑一次 Performance Audit，确认 LCP 元素确实是这张图，且其“Largest Contentful Paint element”详情里显示
loading: eager - 在 iOS Safari 15.4 设备上手动滚动测试：如果首屏图闪一下才出现，大概率是 eager 没生效，或被其他 JS 动态修改了
src
最隐蔽的问题往往出在“本该 eager 却被框架覆盖”——比如某个 UI 库内部封装了 <img> 组件，默认加了 loading="lazy"，而你只传了 src，忘了覆盖这个 prop。
