预加载资源前须检测 fetch() 或 XMLHttpRequest 支持性，降级时设 xhr.responseType = 'arraybuffer'，确保 document.readyState 为 'interactive' 或 'complete' 后再执行，link rel="preload" 需配 crossorigin 与精确 as 值，批量预加载需节流并发、区分大文件延迟加载，并校验 MIME 类型与缓存策略。
预加载资源前必须判断是否支持 fetch() 或 XMLHttpRequest
不是所有目标环境都支持现代 API。比如 iOS Safari 10.3 以下不支持 fetch() 的 cache: 'force-cache'，而老版 Android WebView 可能连 Promise 都不完整。直接调用会静默失败或抛 ReferenceError。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
typeof fetch !== 'undefined' && fetch.toString().includes('function')做基础检测，比仅检查fetch存在更可靠 - 降级到
XMLHttpRequest时，务必设xhr.responseType = 'arraybuffer'，否则图片/音频解码可能出错 - 避免在
document.write()已执行后触发预加载——此时 DOM 可能未就绪，document.readyState应为'interactive'或'complete'才安全
link rel="preload" 只对当前导航有效，不能跨页面复用
很多人以为写个 就能全局缓存，其实它只在当前 HTML 加载阶段生效，且浏览器不会自动将预加载资源注入后续 fetch() 的缓存策略中。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 必须配合
crossorigin属性（哪怕资源同源），否则字体、带 CORS 的 JSON 等会被拒绝解析 -
as值必须精确：JSON 用as="fetch"，WebP 用as="image"，WASM 用as="script"，错一个就会退化为普通请求 - 不要依赖它完成「资源校验」——预加载成功不等于可解码，仍需在
fetch().then(r => r.json())中捕获SyntaxError
动画资源批量预加载时，要控制并发数，别压垮低端设备
一次性 fetch() 20 个 PNG + 1 个 Lottie JSON，在内存 2GB 的安卓机上大概率触发 OOM 或主线程卡死，尤其 Chrome for Android 默认限制并发连接数为 6。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
Promise.allSettled()替代Promise.all()，单个失败不影响整体流程 - 手动节流：每批最多 4 个请求，用
for...of+await控制节奏，例如：
const urls = ['a.png', 'b.png', 'c.png', 'd.png', 'e.png'];
const chunkSize = 4;
for (let i = 0; i < urls.length; i += chunkSize) {
const chunk = urls.slice(i, i + chunkSize);
await Promise.allSettled(chunk.map(u => fetch(u).then(r => r.arrayBuffer())));
}
- 对大文件（>1MB）单独标记，延迟到
requestIdleCallback()中加载，避免阻塞首帧渲染
预加载后资源没被动画框架识别？检查缓存策略和 MIME 类型
Lottie Web、GSAP 或自研 Canvas 动画常因资源未按预期方式加载而报 TypeError: Cannot read property 'length' of null，根源往往是服务端返回的 Content-Type 错了，或客户端缓存头导致重复解析失败。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 确保服务端对 JSON 资源返回
Content-Type: application/json，对 WebP 返回image/webp，否则response.json()会抛Unexpected token - 预加载后若用
URL.createObjectURL(new Blob([buf], {type: 'image/webp'}))创建 URL，记得后续调用URL.revokeObjectURL()，否则内存泄漏极快 - 开发期用 Chrome DevTools 的
Network → Size列确认是否命中内存缓存（from memory cache），而不是磁盘缓存（from disk cache）——后者仍需解码开销
