JavaScript缓存技巧与策略详解

你在学习文章相关的知识吗？本文《JavaScript缓存实现与策略解析》，主要介绍的内容就涉及到，如果你想提升自己的开发能力，就不要错过这篇文章，大家要知道编程理论基础和实战操作都是不可或缺的哦！

缓存应按需选择localStorage（持久但阻塞）、sessionStorage（会话级）或内存对象（快但易泄漏）；需手动加TTL防失效，LRU用Map实现更可靠；敏感、非幂等、实时性高数据不应缓存。

缓存该存在哪？localStorage、sessionStorage 和内存对象各有什么坑

JavaScript 中没有“内置缓存机制”，所谓缓存全靠你自己选地方存。最常用的是 localStorage、sessionStorage 和纯内存对象（比如 const cache = new Map()），但它们行为差异极大：

• localStorage 持久化，跨页面/刷新存活，但只能存字符串，且有容量限制（通常 5–10MB），写入会阻塞主线程；序列化大对象时容易触发 QuotaExceededError
• sessionStorage 仅限当前 tab 生命周期，关掉就丢，同样只支持字符串，不跨 tab 共享，适合临时会话级缓存
• 内存对象（如 Map 或普通 Object）最快，无序列化开销，但页面刷新即清空；若缓存大量数据，可能引发内存泄漏——尤其监听了未解绑的事件或闭包持有 DOM 引用时

怎么加过期时间？手动维护 TTL 是最常见也最容易出错的方式

浏览器原生存储都不带自动过期，必须自己加时间戳字段。常见错误是只存值，不存时间，或者用 Date.now() 存但没在读取时校验：

const cache = new Map();
function setWithTTL(key, value, ttlMs = 5  60  1000) {
cache.set(key, {
value,
expiresAt: Date.now() + ttlMs
});
}
function get(key) {
const item = cache.get(key);
if (!item) return undefined;
if (Date.now() > item.expiresAt) {
cache.delete(key);
return undefined;
}
return item.value;
}

• 别用 setTimeout 清理过期项——页面后台或休眠时定时器会不准，且无法覆盖所有 key
• 如果用 localStorage，记得每次 setItem 前 JSON.stringify，读取后 JSON.parse，否则时间戳会变成字符串导致比较失效
• TTL 单位务必统一：后端返回的过期时间可能是秒（expires_in: 300），前端代码里却当毫秒用，缓存立刻失效

LRU 缓存怎么手写？Map 的插入顺序特性是关键

当缓存容量有限（比如最多存 100 条），LRU（Least Recently Used）是最实用策略。JavaScript 的 Map 保证迭代顺序为插入顺序，正好用来模拟访问序：

class LRUCache {
  constructor(maxSize = 100) {
    this.cache = new Map();
    this.maxSize = maxSize;
  }
get(key) {
if (!this.cache.has(key)) return undefined;
const value = this.cache.get(key);
this.cache.delete(key); // 移到末尾 → 最近使用
this.cache.set(key, value);
return value;
}
set(key, value) {
if (this.cache.has(key)) {
this.cache.delete(key);
} else if (this.cache.size >= this.maxSize) {
this.cache.delete(this.cache.keys().next().value); // 删除第一个（最久未用）
}
this.cache.set(key, value);
}
}

• 别用 Object 实现 LRU：ES2015+ 虽然规定对象属性遍历顺序，但不如 Map 明确可靠，且删除首属性要遍历 keys，性能差
• 注意 this.cache.keys().next().value 是获取第一个 key 的标准写法，不是 this.cache.keys().next()（后者返回的是迭代器对象）
• 如果需要支持异步操作（如缓存 Promise 结果），set 时直接存 Promise，get 时不做 await，由调用方决定是否等待——避免重复触发请求

哪些场景不该缓存？接口幂等性、用户态和敏感数据是硬边界

缓存不是万能胶，强行套用反而引入 bug：

• POST/PUT/DELETE 接口默认不缓存——除非你明确知道该请求幂等且结果可复用（比如提交表单后轮询状态，可缓存轮询响应）
• 用户私有数据（如个人订单列表）不能跨用户共享缓存；多账号切换时，若用全局 Map 缓存，旧用户数据可能被新用户看到
• 密码、token、身份证号等敏感字段，即使加密也不建议进前端缓存；localStorage 可被 XSS 直接读取，风险极高
• 实时性要求高的场景（如股票报价、聊天消息），缓存 TTL 设再短也不如禁用缓存 + 后端做 ETag/Last-Modified 校验来得干净

真正难的不是实现缓存逻辑，而是判断某次请求「值不值得缓」——这取决于接口语义、数据更新频率、用户预期，而不是技术能不能做。

理论要掌握，实操不能落！以上关于《JavaScript缓存技巧与策略详解》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！