HTML怎么做localStorage封装_HTML localStorage工具类封装附代码

直接用 localStorage.setItem 易出问题，因其仅支持字符串：存对象变"[object Object]"，null/undefined转字符串，iOS隐私模式下写入抛QuotaExceededError且静默失败；故封装须守住序列化-反序列化与错误兜底两条底线。

为什么直接用 localStorage.setItem 容易出问题

因为 localStorage 只支持字符串，存对象会变成 [object Object]，取出来还是字符串；存 null 或 undefined 会转成字符串 "null" 或 "undefined"；还有可能触发 QuotaExceededError（尤其 iOS Safari 隐私模式下根本不可写）。这些都不是“功能没实现”，而是运行时静默失败或数据错乱。

所以封装第一件事不是加语法糖，而是守住「序列化-反序列化」和「错误兜底」两条底线：

• set 前强制 JSON.stringify，并捕获异常，失败时明确抛出或返回 false
• get 后强制 JSON.parse，对非 JSON 字符串（如原始字符串 "hello"）做兼容处理，避免 SyntaxError
• 所有方法默认不覆盖原生行为，比如 remove 就是 localStorage.removeItem 的透传，不额外加逻辑

怎么让 get 支持默认值且不崩

原生 localStorage.getItem 返回 null，但你不能直接 JSON.parse(null) —— 会报错。更麻烦的是，有些 key 存的就是纯字符串（比如 localStorage.setItem('theme', 'dark')），不是 JSON，JSON.parse 也会挂。

安全做法是：先判断值是否为 null 或 undefined，再尝试解析，解析失败就原样返回（或返回默认值）：

立即学习“前端免费学习笔记（深入）”；

function get(key, defaultValue = null) {  const raw = localStorage.getItem(key);  if (raw === null) return defaultValue;  try {    return JSON.parse(raw);  } catch {    return raw; // 原始字符串、数字等非 JSON 内容直接返回  }}

这个逻辑比“统一包装成 JSON”更贴近真实场景：你既可能存配置对象，也可能存 token 字符串、开关布尔值（存成 "true"）、甚至时间戳数字。

set 方法必须检查容量并降级吗

必须检查，但「降级」要看场景。iOS Safari 隐私模式下 localStorage 写入直接抛 QuotaExceededError，且无法通过 localStorage.length 预判——它永远返回 0。所以不能靠“剩余空间”判断，只能靠 try/catch。

常见错误是只 catch 一次就放弃，导致用户刷新后数据全丢。稳妥做法是：catch 到写入失败时，记录日志 + 返回 false，由业务层决定是否 fallback 到内存缓存（Map）或提示用户：

• 不要自动切到 sessionStorage：它生命周期不同，容易引发状态不一致
• 不要静默吞掉错误：开发者需要知道持久化失败了
• 如果项目已用 redux-persist 等库，注意它内部的 storage adapter 是否已处理该异常

要不要加过期时间支持

原生 localStorage 没有过期机制，硬加会引入复杂度：每次 get 都要读时间戳、比对、清理，影响性能；同时增加存储体积（每个值多存一个 expires 字段）。

更轻量的做法是「业务侧控制」：比如存的时候自带时间字段，读出来由调用方判断是否过期：

const cache = { value: data, expires: Date.now() + 1000 * 60 * 60 }; // 1小时localStorage.setItem('token', JSON.stringify(cache));<p>// 使用时const cached = get('token');if (cached && cached.expires > Date.now()) {use(cached.value);}

强行在工具类里塞 setWithExpire 和自动清理逻辑，反而会让使用者误以为“过期自动删”，结果发现没删——因为清理只发生在 get 时，而某些 key 可能长期不读。这种隐式行为比显式判断更难调试。