预加载应聚焦首屏关键资源而非多屏图片：首屏图用<link rel="preload" as="image" fetchpriority="high">且href为静态路径；交互后资源用new Image()控制并发与状态；确定性非首屏图用<img loading="eager">软预加载。
预加载“多屏图片”本身是个危险信号——浏览器没有“多屏”概念，只有“首屏关键资源”和“用户行为路径”。盲目预加载第2、3、4屏的图，90%以上会白耗流量、挤占带宽、拖慢首屏。真正要做的不是“多屏预加载”，而是按确定性分阶段调度：哪些图1秒内必显？哪些图在用户滑动/点击后500ms内必用？剩下的，一律交给懒加载或按需触发。
首屏关键图必须用 <link rel="preload"> 且写对参数
这是唯一能在 HTML 解析早期就发起请求的方式，适用于 banner、logo、登录框主图等打开即见的资源。
-
as="image"缺一不可：不写就当普通 fetch 处理，不进图片缓存池、不解码优化、优先级被压低 -
href必须是静态绝对路径（如/assets/hero.webp），不能含 JS 变量或模板语法（/assets/${name}.webp会直接 404） -
fetchpriority="high"在 Chrome 101+ 有效，能抢在部分 CSS/JS 前发请求；旧版忽略无副作用 - 别和
loading="lazy"同时用——逻辑冲突，浏览器可能直接忽略 preload
用户交互后才需要的图，用 new Image() 控制并发与状态
比如轮播图滑到第3页时预载第4、5页，或 hover 商品卡片时预载详情页大图。这时 <link> 失效，必须靠 JS 主动控制。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 顺序不能错：先绑定
onload/onerror，再赋值src；否则缓存命中时事件同步触发，回调直接丢失 - 必须检查
img.complete：为true说明已缓存，需立刻走成功逻辑，不能等 onload - 并发数要节制：同域通常限 6–8 个连接，批量预加载建议用 Promise 队列（例如每次最多 4 个）
- 弱网兜底：先查
navigator.connection?.effectiveType，值为'2g'或'slow-2g'时跳过或降级（如只拉缩略图）
非首屏但确定会用的图，用 <img loading="eager"> 软预加载
比如折叠面板展开后必显的图、Tab 切换后立即呈现的内容图。它们不属于首屏，但用户点击后不能等网络延迟——这时不用 JS，靠浏览器原生 eager 加载机制更稳。
立即学习“前端免费学习笔记（深入）”；
-
loading="eager"是默认行为，显式写出更明确，且可避免被父级loading="lazy"继承影响 - 确保这些
<img>标签在 DOM 中位置靠前（如放在<main>开头），浏览器解析到就会开始请求 - 别加
display: none或visibility: hidden——部分浏览器会推迟 eager 加载，直到元素进入渲染流 - 配合
decoding="async"可防解码阻塞主线程，但不影响下载时机
最容易被忽略的点是：预加载不是“越多越好”，而是“只加载真正确定会用、且加载时机精准可控”的资源。一旦你发现某张图是否加载取决于用户滚动深度、点击路径或设备判断，它就不该出现在 <link rel="preload"> 里——那是 new Image() 或 loading="eager" 的职责边界。
