移动端预加载图片需严格适配：仅对1秒内必显、路径确定、无响应式歧义的图用link rel="preload"，href须根相对或绝对，加as="image"，fetchpriority="high"可选；new Image()前须检测弱网和节电状态。
移动端预加载图片不能照搬桌面端逻辑——网络更不稳定、并发更受限、节电策略更激进，盲目 preload 或密集 new Image() 很可能白发请求甚至拖慢首屏。核心是：只对「1 秒内必显 + 路径确定 + 无响应式歧义」的图做预加载，并主动适配移动端特性。
移动端必须用 link rel="preload"，且路径必须是根相对或绝对
移动端浏览器（尤其是 Safari）对 link rel="preload" 的解析更严格，相对路径容易因 HTML 文件位置变化而 404，直接浪费流量。
-
href必须写成/images/banner.webp或https://cdn.example.com/logo.png，绝不能是./banner.webp或images/banner.webp - 必须写
as="image"，否则 iOS Safari 可能完全忽略该 preload，或降级为低优先级 fetch -
fetchpriority="high"在 Chrome for Android 109+ 有效，但 Safari 不支持——它不报错也不生效，可放心加 - 别在
里放preload，移动端 preload scanner 更保守，外的标签大概率被跳过
用 new Image() 前必须检查网络类型和节电状态
移动端弱网（navigator.connection?.effectiveType === '2g'）或系统节电模式下，new Image().src = url 可能静默失败，用户毫无感知。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 先判断：
if (navigator.connection?.effectiveType && ['2g', 'slow-2g'].includes(navigator.connection.effectiveType))，直接跳过预加载 - 再查节电：
if (navigator.deviceMemory && navigator.deviceMemory （低端安卓），建议降级为只预加载缩略图或跳过 - 赋值
src前，一定先绑定onload/onerror，否则缓存命中时事件同步触发，回调丢失 - 并发控制更关键：iOS Safari 同域并发上限常为 4~6，建议用 Promise 队列，每次最多 3 个，避免阻塞主资源
轮播图/Tab 切换等交互场景，只预加载相邻项
移动端屏幕小、操作路径短，用户滑动后立刻看到下一张的概率极高，但预加载全部后续图就是浪费——尤其在 3G 或节电模式下。
立即学习“前端免费学习笔记（深入）”；
- 初始化时只预加载
currentIndex - 1、currentIndex、currentIndex + 1对应的图（共 3 张） - 滑动到新页后，立刻触发预加载：新
currentIndex - 1和currentIndex + 1（去掉旧的，补上新的边界） - 每张图用独立
new Image()实例，不要复用；加载完成后清空src（img.src = ''）避免内存泄漏 - 如果某张图已存在（
img.complete === true），立即走成功逻辑，不等 onload
最易被忽略的是：预加载的 URL 必须和最终 <img src alt="HTML怎么在移动端预加载图片" > 完全一致——包括大小写、斜杠方向、query 参数。构建工具自动加 hash 时，preload 的 href 必须同步更新，硬编码路径在移动端上线后极易 404，且很难被监控捕获。
