link rel="preload"本身无并发限制，但一次性声明20+会触发降级、抢占带宽、无法条件判断；应仅对3–5张首屏必现图使用，其余交由new Image()节流控制。
用 link rel="preload" 一次性声明会卡死吗
会。浏览器对 link rel="preload" 没有并发数限制，但大量声明（比如 20+ 张）会导致：请求队列爆炸、抢占关键资源带宽、触发 Chrome 的“预加载降级”（自动转为低优先级 fetch），反而拖慢首屏。更糟的是，它不支持条件判断——你无法跳过已缓存的图，也无法按设备像素比动态选图。
建议只对真正首屏必现的 3–5 张图使用，例如 banner、logo、登录框主图。其余一律走运行时控制。
new Image() 批量预加载怎么不压垮浏览器
核心是节流 + 状态感知。直接循环 new Image() 十几张，大概率触发浏览器并发上限（通常 6–8 个），后续请求排队，主线程卡顿，甚至内存飙升。
- 必须先绑定
onload/onerror，再赋值src；否则缓存命中时事件同步触发，回调丢失 - 赋值后立刻检查
img.complete：为true就说明已缓存，可立即执行成功逻辑 - 用 Promise 队列控制并发，例如每次最多 4 个：
Promise.allSettled(chunk)+setTimeout错峰启动 - 避免长期持有 Image 实例引用，加载完可设
img.src = ''或置 null，防止 GC 延迟
WebP + fallback 预加载容易漏掉什么
WebP 图片用 link rel="preload" 时，如果浏览器不支持 WebP（如 Safari 16 以下），它会静默失败——既不加载 fallback，也不报错，最终页面白图或回退到 src 的 JPEG，但此时已错过预加载窗口。
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
安全做法是：只对确定支持 WebP 的环境（通过 document.createElement('canvas').toDataURL('image/webp').indexOf('data:image/webp') > -1 检测）才 preload WebP；否则直接 preload JPEG。不要在 href 里写条件模板，link 是纯静态声明。
预加载后放大/动画仍卡顿？解码没做完
预加载只是把字节拉进缓存，不代表图像已解码。首次 opacity 或 transform 动画时，浏览器才开始解码 → GPU 上传 → 合成，极易掉帧。
解决办法只有两个：
- 对关键动画图，调用
img.decode()（返回 Promise），等它 resolve 再激活动画类 - 或者用“预演法”：在隐藏状态下给图加一次
width: 100%; opacity: 1过渡（配合visibility: hidden），强制完成解码和光栅化，再移除类
注意：img.decode() 会立即触发下载和解码，别对用户大概率不会点开的图滥用。
