缓存应按需选择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：
立即学习“Java免费学习笔记（深入）”；
- POST/PUT/DELETE 接口默认不缓存——除非你明确知道该请求幂等且结果可复用（比如提交表单后轮询状态，可缓存轮询响应）
- 用户私有数据（如个人订单列表）不能跨用户共享缓存；多账号切换时，若用全局
Map缓存，旧用户数据可能被新用户看到 - 密码、token、身份证号等敏感字段，即使加密也不建议进前端缓存；
localStorage可被 XSS 直接读取，风险极高 - 实时性要求高的场景（如股票报价、聊天消息），缓存 TTL 设再短也不如禁用缓存 + 后端做 ETag/Last-Modified 校验来得干净
真正难的不是实现缓存逻辑，而是判断某次请求「值不值得缓」——这取决于接口语义、数据更新频率、用户预期，而不是技术能不能做。
