缓存策略核心是“算过即存、再用即取”，需按场景选层级：内存缓存适高频小数据，localStorage适低频持久化，浏览器缓存专治GET请求；函数级记忆化推荐闭包+Map实现，要求参数可序列化、防缓存爆炸；localStorage需语义化key、带TTL校验，仅用于只读数据；浏览器自动缓存依赖后端Cache-Control与ETag；pending Map则解决并发重复请求，配合AbortController实现请求取消。
用缓存策略避免重复计算，核心是把“算过的结果存起来，下次直接取”，而不是每次都重跑逻辑。关键不在于堆代码，而在于选对缓存层级和适用场景——内存缓存适合高频小数据，localStorage 适合低频持久化，浏览器缓存则专治 GET 请求的网络重复。
用闭包 + Map 实现函数级记忆化（推荐用于纯计算）
这是最轻量、最可控的方式，特别适合递归、格式转换、坐标计算等无副作用的纯函数：
- 外层函数创建一个私有 Map，内层函数通过闭包持续访问它，确保缓存不被垃圾回收
- 参数需可序列化：单参数可用 String()，多参数建议用 JSON.stringify([a, b, c]) 生成唯一 key
- 避免缓存爆炸：可加 size 限制或 LRU 策略（如用第三方库 lru-cache 或手写淘汰逻辑）
- 示例：计算字符串 MD5 前缀时，对同一字符串反复调用无需重算
用 localStorage 管理中长期查询结果（适合配置类、字典类数据）
当后端不支持 Cache-Control、或你需要按用户维度隔离缓存时，localStorage 是可靠补充：
- 拼接 key 要带业务语义，比如 cache_user_profile_123，避免全局冲突
- 存入时附带时间戳和有效期，读取前校验是否过期（如 TTL 设为 30 分钟）
- 仅用于 GET 类只读数据，禁止缓存 POST/PUT 结果
- 注意：localStorage 是同步阻塞 API，大数据量（>1MB）可能卡主线程，建议搭配 try/catch 和降级逻辑
让浏览器自动缓存 GET 请求（零代码但依赖后端配合）
很多重复请求其实根本不用前端干预，只要后端正确设置响应头，fetch 或 axios 就会自动走缓存：
立即学习“Java免费学习笔记（深入）”；
- 确保 URL 稳定：去掉随机参数（如 ts=、_t=），用语义化 query（如 ?type=city&lang=zh）
- 后端返回 Cache-Control: public, max-age=1800（30 分钟），浏览器会在有效期内直接从磁盘/内存读取
- 配合 ETag：服务端根据数据内容生成标识，客户端发 If-None-Match，命中则返回 304，省流量又省解析
- 注意：该机制对 POST、带 credentials 的请求无效，也受 no-cache 等 meta 标签影响
用 pending Map 防止并发重复请求（解决“连点”“快速切换”问题）
缓存解决的是“隔段时间再要”，pending 控制的是“同一秒点了三次”——两者互补：
- 构造请求 key（如 GET:/api/search?q=react），Map 中存 Promise 实例
- 新请求进来先查 Map：存在就复用旧 Promise，不存在才发起 fetch 并存入
- 结合 AbortController，在路由跳转或输入变化时主动 abort 旧请求，避免浪费
- 适合搜索框联想、筛选条件切换、分页加载等用户高频交互场景
