link rel="preload"是唯一真正提前加载活动页面图片的方式，必须静态写在<head>中<meta charset>后、<title>前，as="image"且路径完全一致，否则降级为Low优先级fetch并静默失效。
link rel="preload" 是唯一能真正提前加载活动页面图片的配置方式，其他写法基本无效或起反作用。
必须把 link rel="preload" 写在 <head> 最前面
浏览器只在 HTML 解析初期识别它，一旦遇到 <body> 或任何 <script>，后续插入的 link 就彻底被忽略。动态用 JS 创建、或放在 CSS 后面、<title> 后面，都等于没写。
-
<meta charset="utf-8">后立刻写，顺序不能错 - 每张图一行，不要合并 href 参数
- 路径必须是绝对路径或根相对路径（如
/assets/banner.webp），不能是./images/这种文档相对路径——HTML 文件位置一变就 404
as="image" 缺一不可，写错就静默失效
漏掉 as，或写成 as="img"、as="picture"、as="fetch"，浏览器会降级为普通 fetch，Priority 显示 Low，Initiator 是 (Other)，资源进缓存但优先级拉不起来。
- 必须严格写
as="image" - WebP 图片也要这么写，不需要额外声明 MIME 类型
- 如果同时提供 JPEG fallback，只预加载 WebP 即可；fallback 由
<picture>自动处理，不用重复 preload
活动页首屏图建议加 fetchpriority="high"
Chrome 101+ 支持该属性，对 banner、主视觉、CTA 按钮图等关键资源能进一步抬高网络请求优先级。旧版浏览器直接忽略，无副作用。
立即学习“前端免费学习笔记（深入）”；
- 只对确定“马上要用”的图加，比如活动页顶部大图、倒计时背景、奖品图标
- 不要给所有图都加，否则失去优先级区分意义
- 避免和
loading="lazy"同时出现——逻辑冲突，浏览器可能直接忽略 preload
轮播图或交互图用 new Image() 动态控制
活动页常有“滑到第 2 页才需要第 3 张图”这类场景，link rel="preload" 无法满足。此时必须用 JS 控制，但顺序和并发要小心。
- 先绑定
onload/onerror，再赋值src，否则缓存命中时事件直接同步触发，回调丢失 - 检查
img.complete：为 true 就立刻 resolve，别等 onload - 一次预加载别超过 4 张，浏览器并发限制通常是 6~8，留余量给其他资源
- 示例封装：
const preloadImage = (url) => { return new Promise((resolve, reject) => { const img = new Image(); img.onload = () => resolve(img); img.onerror = () => reject(new Error(`Failed to load ${url}`)); img.src = url; }); };
最容易被忽略的是路径解析规则和 as 的强制性——它不是提示，是硬性要求。写错一个字符，preload 就归零，而 Network 面板里还看不出明显报错，只能靠 Priority 列和 Initiator 字段判断是否生效。
