LocalStorage可记录资源加载状态，关键在于埋点结构设计（type/url/status/ts/buildId）、覆盖动态加载/懒加载/预加载的监听时机、防抖批量存储及容错上传清理机制。
可以直接用 LocalStorage 记录静态资源加载状态，但关键不在“存”，而在“怎么设计埋点结构、何时触发、如何保障数据不丢”。核心目标是准确统计 JS/CSS/图片等资源是否成功加载，尤其在网络弱、缓存失效或 CDN 异常时提供真实失败率。
埋点字段设计：轻量且可归因
每条记录应包含最小必要信息，避免冗余：
-
资源类型（type）：如
"js"、"css"、"img"，便于分类统计 -
资源路径（url）：取相对路径或截断哈希部分（如
"app.a1b2c3.js"），不存完整带域名长 URL -
加载结果（status）：固定值
"success"或"error"，不用布尔值，方便后续日志解析 -
触发时间（ts）：用
Date.now()，精度到毫秒，用于排查时序问题 - 上下文标识（pageId 或 buildId）：可选，但推荐。比如当前页面路由或构建版本号，用于关联发布与异常突增
示例数据：{"type":"js","url":"vendor.8f3a2d.js","status":"error","ts":1718234567890,"buildId":"20260428"}
监听时机：覆盖主流加载方式
不能只靠 onload/onerror，要适配不同资源加载逻辑：
立即学习“前端免费学习笔记（深入）”；
-
脚本动态加载：用
document.createElement('script')插入时，显式绑定onload和onerror回调，触发对应埋点 -
CSS 动态加载：创建
<link rel="stylesheet">后，可用link.sheet是否为 null 判断是否加载完成；失败时监听onerror -
图片懒加载：在
IntersectionObserver触发后尝试img.src，再监听其onload/onerror -
预加载资源（
<link rel="preload">）：需配合PerformanceObserver监听"resource"类型条目，筛选出initiatorType === "preload"且name匹配目标 URL 的记录
存储策略：防抖 + 批量 + 容错
高频资源加载可能一秒内触发数十次，直接写 LocalStorage 会卡顿且易超限：
- 内存中维护一个临时数组（如
window.__resLogQueue = []），所有埋点先推入队列 - 用
setTimeout或requestIdleCallback做节流，例如 500ms 内最多合并写一次 - 写入前检查容量：用
JSON.stringify(queue).length预估大小，单次写入建议 ≤ 1.5KB；总缓存不超过 3MB - 若写入失败（如 QuotaExceededError），降级为仅保留最近 5 条，丢弃最旧非关键项（如重复的 success）
上传与清理：确保数据落地
LocalStorage 只是中转站，必须上传到服务端才算有效埋点：
- 页面卸载前（
beforeunload）：尝试用navigator.sendBeacon发送剩余队列，不等待响应 - 空闲时自动上传：用
requestIdleCallback每 3 秒检查一次，有数据就发起fetchPOST 请求 - 上传成功后，清空对应 key（如
localStorage.removeItem('resLoadLog')）；若失败，将失败数据重新拼回队列并标记重试次数（最多 2 次） - 启动时读取残留数据：页面加载后立即读取
resLoadLog，合并进当前队列，避免冷启动丢失
