全站公共图片指所有页面均使用、url完全一致、无动态参数且不依赖用户态或设备特性的图片；如/logo.webp、/icons/share.svg、/images/404.jpg，需用静态声明于中。
全站公共图片（比如 logo、导航图标、通用 icon、404 页面图）适合用 <link rel="preload"> 静态声明，但必须严格满足「路径确定、数量有限、不随状态变化」三个前提；否则会白加载、404 或拖慢首屏。
哪些图算“全站公共图片”？
判断标准不是“长得像”，而是：所有页面都用、URL 完全一致、不带动态参数、不依赖用户登录态或设备特性。常见例子：
-
/assets/logo.webp（不带?v=xxx，不根据 dark mode 切换路径） -
/icons/share.svg（不是/icons/share-${lang}.svg） -
/images/404.jpg（错误页图，路径固定）
反例：/avatars/default@2x.jpg（可能被 JS 根据 window.devicePixelRatio 动态替换）、/banners/home-${env}.jpg（环境变量注入）、/icons/menu-active.png（只在某个路由下才用）——这些都不适合全局预加载。
必须写在 里且路径静态
这是唯一能安全覆盖全站的方案，但容易因路径或位置出错失效：
- 必须放在
最早位置，不能靠 JS 动态插入 -
href值必须是完整静态字符串，比如href="/assets/logo.webp"，不能是href="./logo.webp"（相对路径易受 HTML 文件位置影响） - 必须写
as="image"，否则浏览器当普通资源 fetch，不走图片缓存策略 - 如果用了 WebP，建议同时提供 fallback 的
<link rel="prefetch">或服务端协商，避免旧浏览器解码失败
示例（正确）：
<link rel="preload" as="image" href="/assets/logo.webp" fetchpriority="high"><link rel="preload" as="image" href="/icons/close.svg">
别用 new Image() 全局预加载公共图
看似灵活，实际在全站场景下风险高：
- 每个页面 JS 执行时都 new 一遍，重复触发相同 URL 请求，浪费带宽
- 如果某张图 404，
onerror不会抛异常，但控制台静默失败，难以发现 - 并发限制（通常 6~8 个）会被公共图占满，挤掉首屏业务图请求
- 无法和构建流程联动：比如你用 Webpack 构建，public 图路径哈希了，但 JS 里写的还是旧名，直接 404
除非你有明确运行时逻辑（比如按用户地区加载不同语言 icon），否则不用它处理“全站公共”这个维度。
WebP + fallback 要手动兜底
预加载 WebP 图时，旧版 Safari 或 IE 会直接失败（不降级）。不能指望浏览器自动 fallback：
- 不要只写
<link rel="preload" as="image" href="/logo.webp"> - 推荐组合：
<link rel="preload" as="image" href="/logo.webp">+<link rel="preload" as="image" href="/logo.png" media="not all and (color)">（粗略检测不支持 WebP 的 UA） - 更稳妥的是服务端根据
Accept请求头返回对应格式，前端统一预加载一个路径，由后端决定返回 WebP 还是 PNG
最容易被忽略的一点：预加载本身不保证渲染，只是把资源放进缓存。如果后续 <img src="/logo.webp"> 的路径和 preload 的 href 字符串不完全一致（比如多了一个斜杠、大小写不同、协议不同），缓存就无法命中——全站统一路径规范比加多少预加载都重要。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
