前端缓存实战：从 localStorage 到 Service Worker 的完整方案

前端干久了，几乎人人都会碰到那种焦头烂额的名场面。我记忆最深的一次线上事故，不是后端数据库被打爆，也不是网关超时，而是本地存储先爆了——一个老用户的 localStorage 写满了，页面所有 setItem 都在静默报错，偏偏那段代码没有做任何容错处理，结果整站白屏，用户投诉电话直接打到客服。那会儿我才真正意识到，平时图省事往 localStorage 里塞的每一条数据，都是要还的。

这篇文章就是来聊这个的：本地存储为什么会爆、爆了怎么救、如何用一套相对完整的缓存方案让页面“秒开”。我会把自己这些年踩过的坑、用过的招数，包括封装、降级、IndexedDB、HTTP 缓存、Service Worker、多标签页同步等等，全部摊开来讲。适合正在写业务代码、被线上性能问题和缓存问题反复折腾的前端同学，也适合准备梳理缓存知识体系、应对面试的进阶开发者。

1. 本地存储爆雷，到底是怎么炸的

本地存储的“爆雷”很少是单一原因，更多是一层层小问题叠出来的。先把事故现场拆开看，后面才好对症下药。

1.1 5MB 魔咒与悄悄膨胀的数据

localStorage 的容量限制，绝大多数浏览器给的是约 5MB，这个数字是基于 UTF-16 编码来算的。也就是说，在不考虑其他开销的情况下，大约能存 5242880 个字符。如果是中文字符，一个汉字按 2 字节估算，真正能存的中文内容大概也就两百多万字。听起来不少，但在真实业务里根本不够花。

我见过最夸张的项目，把接口返回的大列表、图片的 base64、用户埋点数据、草稿内容、购物车快照，全部塞进 localStorage。一开始上线很顺畅，几个月后用户数据越积越多，写入越来越频繁，某天就突然到了上限。这里有个很隐蔽的坑：JSON.stringify 会让数据体积膨胀很多。你存一个业务对象，转成字符串后，键名、嵌套结构、数组方括号，全都变成额外字节。只保留必要字段的对象和完整业务模型序列化后的体积，可以差到好几倍。

还有一个反向的坑：很多人用 localStorage 来缓存接口数据，但忘掉了“缓存过期”这件事。用户打开页面，代码发现 localStorage 里有旧数据就直接渲染，旧数据格式和当前版本不兼容，轻则展示错乱，重则直接抛错。这类问题平时开发环境根本复现不了，因为开发者天天刷新、天天拿新数据，老用户才会中招。

1.2 隐私模式与“悄悄消失”的数据

本地存储的第二类爆雷，是隐私模式带来的。Safari 旧版的隐私模式、部分 Android 内置浏览器的无痕模式，对存储配额的管理和普通模式完全不一样。有的环境是 setItem 直接抛 QuotaExceededError，有的环境则是写入时看着一切正常，刷新后数据就没了。

这种问题最气人的地方在于：开发环境永远复现不了，线上却有部分用户反复中招。一旦代码里没有 try/catch 兜底，存储异常就会顺着调用栈往上抛，把正常渲染流程打断，表现出来就是一片白屏。

同样的坑还出现在“用户主动清数据”的场景。手机系统自带的清理功能、各种安全软件的一键清理、浏览器设置里的清除浏览数据，都会把 localStorage、IndexedDB、Cache Storage 一起带走。如果业务把关键的登录标记、配置信息放在本地存储里，清理后就会出现各种奇怪状态：一会儿自动退出、一会儿配置丢失、一会儿页面错乱。

1.3 多标签页互相踩踏

同源下多个标签页共享同一份 localStorage，但没有任何锁机制。用户开着好几个标签页，A 页面写入了一版草稿，B 页面基于旧数据又回写了一个旧值，A 页面的新内容就被覆盖了。这个问题在协同编辑、表单自动保存这类场景里特别常见。

还有一个容易被忽略的：代码里直接调用 clear()。很多人在用户退出登录时习惯性地执行 localStorage.clear()，想清掉所有痕迹。出发点是好的，但如果同一域名下还有其他业务模块也依赖 localStorage，或者团队里多个项目共用一个域名，一次 clear 就能把别人的数据全清掉。这种情况我在实际项目里见过不止一次，属于典型的“好心办坏事”。

2. 第一招：给 localStorage 穿上防弹衣

本地存储在业务里确实方便，同步 API、即写即读、无需处理回调，所以想完全不用它也不现实。正确的思路是：继续用，但加一层可靠的封装，把所有可能爆雷的路径都提前堵住。

2.1 安全写入与优雅降级

我建议不要在任何业务代码里直接调用 localStorage.setItem，而是统一走封装好的 Storage 模块。这个模块要解决三件事：写入容错、自动过期、解析容错。

先看一个可以直接抄的封装：

javascript复制const memoryStore = new Map();

const SafeStorage = {
  set(key, value, expireSeconds = 0) {
    const payload = {
      data: value,
      expire: expireSeconds > 0 ? Date.now() + expireSeconds * 1000 : 0,
    };
    try {
      window.localStorage.setItem(key, JSON.stringify(payload));
    } catch (e) {
      // 存储失败时降级到内存缓存，保证页面不崩溃
      memoryStore.set(key, payload);
    }
  },

  get(key) {
    let payload = null;
    try {
      const raw = window.localStorage.getItem(key);
      if (!raw) {
        payload = memoryStore.get(key) || null;
      } else {
        payload = JSON.parse(raw);
      }
    } catch (e) {
      // 解析失败就当成没有缓存，交给业务做兜底
      payload = memoryStore.get(key) || null;
    }

    if (!payload) return null;

    // 过期校验
    if (payload.expire && Date.now() > payload.expire) {
      this.remove(key);
      return null;
    }
    return payload.data;
  },

  remove(key) {
    try {
      window.localStorage.removeItem(key);
    } catch (e) {
      memoryStore.delete(key);
    }
  },

  clear() {
    try {
      window.localStorage.clear();
    } catch (e) {
      memoryStore.clear();
    }
  },
};

这段代码核心就一个思想：存储操作绝不能让异常外抛。setItem 报错就降级到 Map，getItem 解析失败就返回 null，让业务侧走自己的兜底逻辑。页面白屏的问题，从这个层面就被彻底掐死了。

2.2 容量预估与数据瘦身

封装解决的是“稳定写入”的问题，但还要尽量让写入的量不要触及上限。我在项目里习惯在 set 之前做一个简单的体积估算：

javascript复制function estimateSize(value) {
  const json = JSON.stringify(value);
  if (!json) return 0;
  // 粗略估算：UTF-16 下，字符串长度并不等于字节数
  return json.length * 2;
}

如果预估超过 1MB，就不走 localStorage，直接走 IndexedDB。这里给个经验阈值：localStorage 适合存小体量、低频写的数据，比如用户偏好、主题配置、token 的临时副本、接口数据的“最后一条快照”。超过了就不要硬塞。

另外，存数据之前先做字段裁剪。举个例子，接口返回一个数组，每一项有 20 个字段，页面上只用 5 个字段，就直接映射成新对象再存。这个操作在数据量大的时候能省掉一半以上空间。再加上合理的过期时间，配合定时清理，localStorage 基本不会再有爆仓的风险。

3. 第二招：大数据量时，果断换 IndexedDB

localStorage 是同步读取，这个特性决定了它不可能承载大数据量。一旦数据量超过几 MB，同步序列化、同步写入都会阻塞主线程，用户能明显感觉到页面卡顿。真正的数据缓存，应该交给 IndexedDB。

3.1 IndexedDB 的核心概念速览

IndexedDB 是浏览器内置的非关系型数据库，容量通常在磁盘可用空间的量级，远大于 localStorage。它有四个核心概念：

• 数据库：一个域名可以建多个库，每个库有版本号，升级时触发 onupgradeneeded。
• 对象仓库：类似关系型数据库的表，但更灵活，直接存对象。
• 索引：给对象的某个字段建索引，方便按条件查询。
• 事务：所有读写都在事务里执行，保证数据一致性。

很多前端同学不适应它，是因为 API 全是异步回调风格。解决方式很简单，封一层 Promise 就好。

3.2 一个可以直接抄的封装

这里给一个 mini 版封装，覆盖常见的增删改查和按索引查询：

javascript复制class IDBStore {
  constructor(dbName, storeName, version = 1) {
    this.dbName = dbName;
    this.storeName = storeName;
    this.version = version;
    this.db = null;
  }

  open() {
    return new Promise((resolve, reject) => {
      const request = indexedDB.open(this.dbName, this.version);
      request.onupgradeneeded = (e) => {
        const db = e.target.result;
        if (!db.objectStoreNames.contains(this.storeName)) {
          db.createObjectStore(this.storeName, { keyPath: 'id' });
        }
      };
      request.onsuccess = (e) => {
        this.db = e.target.result;
        resolve(this.db);
      };
      request.onerror = (e) => reject(e.target.error);
    });
  }

  async set(value) {
    const db = await this.open();
    return new Promise((resolve, reject) => {
      const tx = db.transaction(this.storeName, 'readwrite');
      tx.objectStore(this.storeName).put(value);
      tx.oncomplete = () => resolve();
      tx.onerror = (e) => reject(e.target.error);
    });
  }

  async get(key) {
    const db = await this.open();
    return new Promise((resolve, reject) => {
      const tx = db.transaction(this.storeName, 'readonly');
      const request = tx.objectStore(this.storeName).get(key);
      request.onsuccess = () => resolve(request.result || null);
      request.onerror = (e) => reject(e.target.error);
    });
  }

  async getAll() {
    const db = await this.open();
    return new Promise((resolve, reject) => {
      const tx = db.transaction(this.storeName, 'readonly');
      const request = tx.objectStore(this.storeName).getAll();
      request.onsuccess = () => resolve(request.result || []);
      request.onerror = (e) => reject(e.target.error);
    });
  }

  async remove(key) {
    const db = await this.open();
    return new Promise((resolve, reject) => {
      const tx = db.transaction(this.storeName, 'readwrite');
      tx.objectStore(this.storeName).delete(key);
      tx.oncomplete = () => resolve();
      tx.onerror = (e) => reject(e.target.error);
    });
  }
}

注意，上面的 open() 方法每次调用都会重新打开数据库连接，实际项目中建议在实例化后只 open 一次，内部维护 db 引用，避免频繁建连的开销。

3.3 什么场景必须用 IndexedDB

按我自己的标准，遇到下面几种情况直接切 IndexedDB：

• 列表接口缓存：比如聊天记录、订单列表，数据量可能上万条，localStorage 放不下，放得下也会卡。
• 文件类数据：图片 base64、音视频片段，这些用 localStorage 纯属自杀。
• 离线场景：配合 Service Worker 做离线包，缓存 HTML、CSS、JS 资源。
• 需要按字段查询的数据：IndexedDB 能建索引做条件筛，localStorage 只能全量遍历再过滤。

还有一点容易被忽视：IndexedDB 是异步的，读取和序列化都不阻塞主线程，所以配合 Web Worker 做大文件上传、大数据量导入时，体验比 localStorage 好很多。数据量大的页面，首屏就能用异步缓存先把骨架渲染出来，再等接口数据补齐。

4. 第三招：HTTP 缓存策略，让资源不再是“每次重新下载”

本地存储解决的是应用层数据的缓存，而页面能不能秒开，更大程度取决于静态资源走不走 HTTP 缓存。很多项目上线后用户还是访问到旧代码，根源往往就是 HTTP 缓存策略配错了。

4.1 强缓存与协商缓存的分工

HTTP 缓存分两种：强缓存和协商缓存。

强缓存是浏览器在缓存有效期内直接使用本地副本，不发请求到服务器，表现就是 Network 面板里看到的 from disk cache 或 from memory cache。控制它的字段是 Cache-Control，常见取值有：

• max-age=31536000：一年内直接用缓存。
• no-cache：不要直接使用缓存，需要向服务器确认资源是否变化（但服务器返回 304 时仍然用缓存）。
• no-store：完全不用缓存，每次都下载。

协商缓存是浏览器带着上次响应的标识（ETag 或 Last-Modified）去问服务器“这资源变了没”，服务器返回 304 就继续用缓存，返回 200 就用新资源。

实际项目里的标准配置是：给静态资源文件加上 hash 版本号，然后设置一年强缓存。因为文件名一旦变化，就是全新的 URL，浏览器自然会重新下载；没变的文件名，一年内直接用缓存，连请求都不发。

4.2 Nginx 配置实操

下面是一段我在项目中使用过的 Nginx 配置：

nginx复制server {
    listen 80;
    server_name example.com;

    # HTML 文件每次都要验证，保证发布后用户能第一时间拿到新页面
    location / {
        add_header Cache-Control "no-cache";
        try_files $uri $uri/ /index.html;
    }

    # 带 hash 的静态资源，直接一年强缓存
    location /static/ {
        add_header Cache-Control "max-age=31536000, immutable";
    }
}

HTML 设置 no-cache，是为了让浏览器每次都向服务器确认一次页面是否有更新。如果 HTML 本身被强缓存了，那么即使静态资源文件名换了，用户访问到的还是旧的 HTML，也就不会去请求新资源。这是最常见的“发布后用户还是旧版本”的根因，记住一句话：HTML 要实时，静态资源要持久。

4.3 构建工具的 hash 指纹怎么配

使用 Webpack 或 Vite 做构建时，可以在输出文件名中注入 content hash。

Webpack 配置示例：

javascript复制module.exports = {
  output: {
    filename: 'js/[name].[contenthash:8].js',
    chunkFilename: 'js/[name].[contenthash:8].chunk.js',
  },
};

Vite 默认就会生成带 hash 的文件。每次代码变化，文件名就变，缓存自然失效。这套机制搭配上面的 Nginx 配置，即使某些资源被强缓存一年，也不会出现“页面还是老代码”的问题。

不过这里有个细节要小心：同一个 chunk 在导出后一定要保持文件名稳定。有时候构建配置调整了，同一段代码的 hash 会变化，导致用户重新下载大量资源。遇到这种情况，检查一下是否开启了 optimization.moduleIds 和 optimization.chunkIds 的确定性配置，别让 hash 被无关信息影响。

5. 第四招：Service Worker 做“本地缓存层”，秒开再加一档

HTTP 缓存再快，也快不过“根本不走网络”。Service Worker 就是能让你在浏览器和多地服务器之间再加一层本地缓存的技术。它本质是一个独立的 JS 线程，可以拦截页面发的所有请求，直接决定是返回缓存还是走网络。

5.1 Service Worker 能做什么，不能做什么

Service Worker 的生命周期是：注册 -> 安装 -> 激活 -> 运行。它能拦截 fetch 请求、操作 Cache Storage、离线缓存静态资源、接收推送消息，但它必须在 HTTPS 环境下运行（localhost 本地开发除外），而且运行在独立线程中，不能直接操作 DOM。

项目的 sw.js 通常放在 public 目录下，在入口文件里注册：

javascript复制if ('serviceWorker' in navigator) {
  window.addEventListener('load', () => {
    navigator.serviceWorker.register('/sw.js');
  });
}

5.2 三种缓存策略的取舍

Service Worker 的缓存策略，我实际用下来最顺手的是这三种：

• Cache First：有缓存直接返回，没有才走网络。适合图片、字体、带 hash 的静态资源。
• Network First：先请求网络，失败时回退到缓存。适合 HTML 页面、关键接口，能保证用户拿到最新的同时提供离线兜底。
• Stale While Revalidate：先返回缓存，同时在后台更新缓存，下次访问就拿到新版本。适合不常变但又希望最终一致的接口数据。

下面是一个可以直接用的 sw.js 例子：

javascript复制const CACHE_NAME = 'my-app-v1';
const STATIC_ASSETS = ['/', '/index.html', '/static/js/main.js'];

self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open(CACHE_NAME).then((cache) => cache.addAll(STATIC_ASSETS))
  );
  self.skipWaiting();
});

self.addEventListener('activate', (event) => {
  event.waitUntil(
    caches.keys().then((keys) =>
      Promise.all(keys.filter((key) => key !== CACHE_NAME).map((key) => caches.delete(key)))
    )
  );
  self.clients.claim();
});

self.addEventListener('fetch', (event) => {
  const url = new URL(event.request.url);

  // 静态资源走 Cache First
  if (url.pathname.includes('/static/')) {
    event.respondWith(
      caches.match(event.request).then((cached) => {
        return (
          cached ||
          fetch(event.request).then((response) => {
            const clone = response.clone();
            caches.open(CACHE_NAME).then((cache) => cache.put(event.request, clone));
            return response;
          })
        );
      })
    );
    return;
  }

  // HTML 走 Network First
  if (event.request.mode === 'navigate') {
    event.respondWith(
      fetch(event.request).then((response) => {
        const clone = response.clone();
        caches.open(CACHE_NAME).then((cache) => cache.put(event.request, clone));
        return response;
      })
      .catch(() => caches.match(event.request))
    );
    return;
  }
});

这里有一个关键点：每个新版本发布时，要手动改变 CACHE_NAME。比如 my-app-v2。因为 install 阶段会新增一个缓存，activate 阶段会清掉旧缓存，这样就能保证用户不会一直访问到旧版本。如果缓存名一直不变，Service Worker 不会自动清理旧资源，老代码就会被一直服务下去。

5.3 SW 上线后的坑

第一坑：开发体验巨差。本地开发改了代码，页面一直被 Service Worker 缓存，看不到新效果，还以为代码写错了。解决方法是开发环境不注册 SW，只有测试和生产环境启用。

第二坑：更新不及时。注册了新 sw.js，但页面首次加载用的还是旧 SW，要等页面刷新一次或多次后才能生效。用 skipWaiting 和 clients.claim() 能加速这个过程，但要注意时机，别在用户操作了一半的时候强行刷新页面。

第三坑：监听起来困难。SW 跑在独立线程里，页面里的 console 看不到它的日志。调试时可以打开 DevTools 的 Application 面板，在 Service Workers 区域能看到当前激活的 SW，也可以勾选 “Update on reload” 方便调试。

6. 第五招：多标签同步与版本管理

本地存储玩到后期，最头疼的是“数据一致性问题”。一个页面写了缓存、另一个页面还在用旧缓存，或者接口升级后旧缓存格式与新版不兼容，这种情况靠单一技术解决不了，必须有全局的版本管理思路。

6.1 storage 事件与 BroadcastChannel 的配合使用

localStorage 有一个原生事件叫 storage，当同源的其他标签页修改 localStorage 时，当前页面会收到通知：

javascript复制window.addEventListener('storage', (event) => {
  if (event.key === 'user_profile') {
    // 刷新当前页面的用户信息
  }
});

这个事件的限制是：触发源页面本身不会收到事件，只有其他标签页能收到。如果业务场景需要当前页面也感知数据变化，那就要用到 BroadcastChannel，它可以主动广播消息，所有监听该 channel 的页面都能收到：

javascript复制const channel = new BroadcastChannel('app-sync');

// A 页面写入数据后广播
channel.postMessage({ type: 'USER_UPDATE', data: userInfo });

// B 页面监听
channel.onmessage = (event) => {
  if (event.data.type === 'USER_UPDATE') {
    updateUI(event.data.data);
  }
};

实际落地时，我的方案是：写入 localStorage 时，同时 postMessage 到 BroadcastChannel。这样不管当前页面还是其他页面，都能第一时间感知变化，数据一致性基本就稳了。

6.2 给缓存加一个“有效期身份证”

版本管理是缓存方案里最容易被忽略、但最关键的一环。我有一个很简单的做法：在 localStorage 里存一个全局版本号 key，比如 app_cache_version。

javascript复制const CACHE_KEY = 'app_cache_version';
const CURRENT_VERSION = '2026.03.01';

// 页面启动时校验版本
const lastVersion = SafeStorage.get(CACHE_KEY);
if (lastVersion !== CURRENT_VERSION) {
  // 版本不一致，清掉所有业务缓存，重新拉取
  removeOldCaches();
  SafeStorage.set(CACHE_KEY, CURRENT_VERSION);
}

这个版本号的来源有两种，要么在前端代码里写死，在发版时手动升级；要么后端通过接口下发，前端启动时拉取对比。手动写死简单直接，适合小型项目；后端下发更灵活，适合接口数据结构变的频繁的复杂项目。

另一个做法是给每个业务缓存 key 加上版本后缀，比如 user_profile_v3、cart_list_v2。读取时先读取当前版本的 key，没有就用默认值，避免直接解析旧版本的数据。这样做虽然会遗留一些永远用不到的旧 key 占用空间，但配合定期的存储空间清理，问题不大。

6.3 退出登录时别乱清

前面提过 clear() 误伤的问题。退登时最安全的方式是只清属于当前业务的 key，而不是全量清空：

javascript复制const REMOVABLE_KEYS = [
  'user_profile',
  'auth_token',
  'cart_list',
  'draft_content',
];

function logoutCleanup() {
  REMOVABLE_KEYS.forEach((key) => SafeStorage.remove(key));
}

如果确实需要全量清理，也要先跟产品确认这个域名下没有别的模块共用存储。更好的方案是给 key 统一加应用前缀，比如 myapp_user_profile，这样清理时按前缀取出来逐个删，既不误伤别人，也能清干净。

7. 页面秒开的实战组合拳

前面五招讲的是方法论，这套组合拳真正落地之后，页面秒开是可以实现的。下面把整条链路串起来。

7.1 多层缓存架构的完整规划

从用户在地址栏输入 URL，到页面首屏出现，这条链路每一步都有对应的缓存策略：

• DNS 解析：域名解析结果由浏览器系统级缓存接管，前端干预不了太多，但可以尽量减少跨域请求的域名数量。
• TCP/TLS 连接：HTTP/2 的多路复用能减少连接建立开销，配合 keep-alive 长连接。
• HTML 资源：走 Network First 策略，每次回源验证，保证新版本快速生效，失败时回退本地缓存。
• CSS/JS/图片/字体：走带 hash 的长缓存，配合 CDN 和 Service Worker 的 Cache First，基本零请求。
• 接口数据：接口响应加 ETag 做协商缓存，业务数据用 IndexedDB 缓存一分钟或几分钟。
• 业务状态：用户偏好、配置项用封装后的 SafeStorage，小数据量、快读写。

为了让策略更清晰，我做了一张表格：

7.2 一次优化案例的实测数据

我在上一个项目里做过一次完整的缓存改造。那是一个中后台系统，改之前首屏加载光 JS 就有 2MB 多，用户每次打开页面都是全新下载，局域网环境还好，但远程办公的网络环境下，首屏白屏时间经常 3 秒以上。

改造做了三件事：

第一，构建产物拆分。把第三方库单独打包，加上 contenthash，这样第三方库不变时，用户永远复用旧缓存。

第二，Nginx 设定强缓存策略。HTML 用 no-cache，静态资源用一年强缓存。

第三，引入 Service Worker。对静态资源做 Cache First，对页面导航做 Network First。

改造后的首屏加载时间，从平均 3.2 秒降到了 1.1 秒。最神奇的是，二次访问时 JS 和 CSS 完全走本地缓存，基本零请求，页面刷新几乎是瞬间完成。这个提升没有改任何业务逻辑，纯粹是缓存策略的胜利。

7.3 缓存方案上线前要注意的细节

缓存方案上线后，一定要让团队成员和测试知道规则。尤其是“强缓存一年”这种配置，如果后续有紧急修 bug、改了静态资源但忘了改文件名，用户就会一直访问旧版本。所以规范的发布流程必须配套：

• 每次前端发布，确保构建工具生成新的 hash 文件名。
• 版本号或 cache name 同步更新。
• 发布后立即在无痕模式或开发者工具中验证一次页面加载，确认拿到的资源是最新的。

8. 常见问题排查与避坑速查

最后把这几年处理本地存储和缓存问题时积累的排查思路整理成一份速查表，遇到问题可以直接对照。

8.1 看板和日志的实战技巧

排查缓存问题时，开发者工具是首选武器：

• Network 面板：看资源有没有走缓存，会显示 from memory cache、from disk cache 或 from ServiceWorker。如果是 200，再看有没有 304。
• Application 面板：Local Storage、Session Storage、IndexedDB、Cache Storage、Service Workers 五个区域全部能查。
• Performance 面板：录制页面加载，能精确看到哪一步耗时最多，是请求等待还是脚本执行。

我还习惯在封装好的 SafeStorage 里加一个无侵入的日志统计，把 setItem 失败的次数、存储占用大小定期上报到监控平台。这样线上出问题，不是等用户投诉，而是监控先报警。

8.2 容易忽略的底层细节

最后分享几个不写在常规文档里、但实战中特别容易踩的细节：

• localStorage 存储的值只能是字符串。存数字 3，取出来是字符串 “3”。所以封装时一定要做 JSON 序列化，类型转换才能保持一致。
• Safari 的隐私模式历史包袱很深。即使在较新版本中，写入失败的概率依然比 Chrome 高出不少，容错处理不能少。
• IndexedDB 在部分浏览器隐身模式下受限。数据写入后可能被直接丢弃，所以关键业务数据不能只依赖 IndexedDB，内存缓存、接口兜底都要有。
• 不要往 localStorage 里存敏感信息。它没有任何加密机制，同源下的任何脚本都能读。真正需要安全保护的 token，建议用 httpOnly cookie 或者短期 SessionStorage 加内存方案，降低 XSS 下数据被批量拿走的概率。

9. 一点过来人的建议

说回开头那次事故。后来我复盘时发现，真正导致白屏的不是 localStorage 满了本身，而是项目里没有任何容错设计，把“存储”当作了一个永远可靠的依赖。从那以后，我给自己的缓存方案定了几条铁律：所有存储操作必须有兜底；所有缓存必须有版本号；所有数据写入前必须考虑容量；所有用户会遇到的异常，都要在代码里提前想好退路。

本地存储和缓存这事儿，看着不难，但每一个细节都能在线上给你挖坑。如果你现在正在处理类似的问题，哪怕是其中一招，我都建议你把它当成一个正经项目来做，写清楚策略、加好监控、做全容错。这五个招数在我负责过的项目里都实际落地过，不能说百分之百完美，但至少让我从“深夜救火”的状态里解脱了出来。下次再遇到本地存储爆雷，希望你能从容地打开 DevTools，按这篇的思路一步步排查出真正的坑。