首屏图片降级必须确保无JS、断网等极端情况下仍能稳定加载可用图，因此src必须写死为真实可访问资源，禁用loading="lazy"，显式设loading="eager"，配合fetchpriority="high"或preload、宽高/aspect-ratio及有效alt，缺一不可。
首屏图片降级不是“加个 onerror 就完事”，而是必须让浏览器在无 JS、断网、CORS 拦截、或旧浏览器等任意一种失效路径下，仍能稳定加载一张可用图——否则用户看到的就是空白、占位符、或布局抖动。
为什么首屏图不能只靠 loading="lazy" 或 onerror
因为这两者都依赖「请求已发出但失败」这个前提，而首屏图的常见失败根本没走到这一步：
-
src=""或src="#"：HTML 解析阶段不发请求，onerror不触发 - 跨域图没加
crossorigin：被 CORS 拦截，控制台报错但onerror静默 - 服务端对 404 返回 200 状态的占位图（如
/img/404.png?text=missing）：浏览器认为“加载成功”，降级逻辑完全跳过 -
loading="lazy"在 Safari ≤15.3 或旧 Android WebView 中被忽略，若此时src是空或无效，直接白屏
必须写死 src，且指向一个真实可访问资源
首屏图的 <img> 标签中，src 属性不能是占位符路径、不能为空、不能是 JS 动态填入——它必须在 HTML 初始渲染时就指向一个确定可用的资源：
- 推荐用 SSR 渲染出的真实小图（如 320px 宽的 WebP 或 JPEG），而非 1px GIF；既保内容，又控流量
- 绝对避免
src="data:image/svg+xml;base64,..."做首屏主图：Base64 过大会拖慢 HTML 解析和首次绘制，且无法被 CDN 缓存 - 若用
<picture>，<img>标签本身仍需带src（作为强制兜底），不能只靠<source> - 关键图禁用
loading="lazy"，显式写loading="eager"，防止浏览器启发式策略误判导致重复加载
如何用 fetchpriority 和 preload 协同保障加载顺序
仅设 src 不够，还要告诉浏览器“这张图很重要，别等别的”：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 对首屏主图（如 banner、商品头图），加
fetchpriority="high"—— 仅 Chromium 112+ 有效，但它是 LCP 稳定性的关键提示 - 配合
<link rel="preload" as="image" href="hero.webp" crossorigin>，确保资源提前进入加载队列；注意href必须与最终<img src>完全一致（含查询参数） - 不要给所有图都加
fetchpriority="high"：浏览器会把它们统一归入 High 队列，反而稀释真正关键资源的调度权重 - 如果已用了
preload，fetchpriority就不再起作用，二者选其一即可，优先用preload（兼容性更好）
alt、宽高、aspect-ratio 是降级链里最易被忽略的一环
这些看似“语义化”或“样式”的属性，实际直接影响降级是否生效：
-
alt不只是无障碍需求：当图片加载失败且无onerror回退时，alt是用户唯一能读到的内容；首屏图的alt必须准确描述图像核心信息（如alt="iPhone 15 Pro 钛金属机身特写"），不能写“图片”或留空 - 必须声明
width和height（或aspect-ratio）：否则 Safari 和部分安卓 WebView 会降级为eager加载，且滚动时发生 CLS（布局偏移） - 避免用
display: none包裹首屏图容器：某些 WebView 下，元素不可见时直接跳过懒加载逻辑，即使后来显示也再不会触发加载
真正可靠的首屏降级，是把每张图当作一个独立服务来设计：它要有确定的初始状态（src）、明确的加载意图（fetchpriority 或 preload）、可读的内容兜底（alt）、以及稳定的渲染尺寸（width/height 或 aspect-ratio）。少一个环节，就可能在某个真实用户的设备上彻底失效。
