imagesizes必须与imagesrcset配套使用，单独声明无效；二者需与对应<img>标签的srcset和sizes逐字符一致，否则预加载无法精准匹配资源，导致重复请求或加载错误版本。
imagesizes必须和imagesrcset一起用，单独写无效
在 <link rel="preload"> 中，imagesizes 不是独立属性，它只在配合 imagesrcset 时才有意义。浏览器靠这两者共同还原 的响应式资源选择逻辑——否则它根本不知道该选哪张图、按什么尺寸算。单独写
imagesizes="50vw" 而不带 imagesrcset，浏览器会忽略该属性，降级为加载 href 指向的单图（如果存在），且无法匹配 srcset 中的高 DPR 版本。
imagesrcset语法必须和对应<img>完全一致
预加载能否命中缓存、是否触发正确分辨率的下载，取决于 imagesrcset 的值是否与页面中真实 <img srcset="..." sizes="..."> 的内容逐字符匹配。哪怕多一个空格、少一个单位（如 400w 写成 400），浏览器都可能当作不同资源处理，导致重复请求或加载错误版本。
-
imagesrcset必须包含所有实际会用到的候选项，顺序无关，但 URL 和宽度描述符（w）或密度描述符（x）要准确 -
imagesizes必须是合法 CSS 长度表达式，比如"100vw"、"(max-width: 768px) 100vw, 50vw"，不能是 JS 表达式或变量 - 如果
用了
srcset但没写sizes，预加载时也**不能省略**imagesizes—— 浏览器默认 fallback 是100vw，但显式写出来更可控
as="image" + imagesrcset 组合只支持静态路径，不支持动态拼接
<link rel="preload"> 是 HTML 解析阶段执行的声明式行为，所有属性值都是纯字符串。这意味着：
-
href、imagesrcset、imagesizes都不能含 JS 变量、模板占位符（如{{url}}）、或任何运行时计算结果 - 无法根据
window.devicePixelRatio或用户偏好动态生成imagesrcset；这类场景必须退回到new Image()方案 - 相对路径仍需基于当前 HTML 文档位置解析，例如 HTML 在
/blog/post.html，则href="img/hero.jpg"实际请求的是/blog/img/hero.jpg，不是根目录下的/img/hero.jpg
Chrome DevTools里验证是否生效的关键点
光看 HTML 里写了没用，得进 Network 面板确认真实行为：
立即学习“前端免费学习笔记（深入）”；
- 筛选
Initiator列为preload，排除 parser 或 script 触发的请求 - 检查
Priority应为High（as="image"的预期值），不是Low（说明as漏写或写错） - 右键请求 → “Copy request headers”，确认
Accept头是否含image/webp（若你提供 WebP 候选项且浏览器支持） - 对比未预加载时的下载起始时间，理想提前量在 200–500ms；若差距极小，大概率是
imagesrcset匹配失败，浏览器退回到了href单图
真正难的不是写对语法，而是让预加载的资源选择逻辑和最终渲染时 的选择逻辑严丝合缝——差一个
w，就可能加载了 400px 图却在 2x 屏上被拉伸模糊。
