最轻量有效的减少重复GET请求方式是在请求层做缓存，需明确缓存对象、时效及清理时机；按完整URL+参数生成唯一key，仅缓存GET请求；用Map+Promise实现防抖与共享；通过时间戳控制5分钟过期；封装为useCachedGet等可复用Composable。
直接在请求层做缓存，是最轻量也最有效的减少重复 GET 请求的方式。关键不是“要不要缓存”，而是“缓存谁、缓存多久、什么时候清掉”。
缓存粒度：按 URL + 参数组合唯一标识
同一个接口不同参数应视为不同缓存项。比如 /api/user?id=1 和 /api/user?id=2 不能共用一个缓存值。
- 推荐把完整请求地址（含 query string）作为缓存 key，避免手动拼接出错
- 对 POST/PUT 等非幂等请求，不建议缓存；GET 请求天然适合缓存
- 若接口支持 ETag 或 Last-Modified，可配合 HTTP 缓存头做双重校验
内存缓存实现：Map + Promise 缓存防抖
用 Map 存储 url → Promise 映射，既能避免重复发起请求，又能共享同一 Promise 结果，防止并发重复调用。
- 请求发起前先查 Map，命中则直接返回已有 Promise
- 未命中则发起新请求，并把 Promise 存入 Map，后续同 URL 请求复用该 Promise
- 请求完成或失败后，可选择性保留或清除该缓存项（例如成功才缓存，失败不缓存）
缓存时效控制：简单过期逻辑就够用
纯内存缓存默认无过期机制，需手动加时间判断。不需要复杂 TTL 管理，基础场景用“创建时间 + 固定有效期”即可。
立即学习“前端免费学习笔记（深入）”；
- 每个缓存项可包装为
{ data, timestamp }对象 - 读取时检查
Date.now() - timestamp < 300000（5 分钟），超时则重新请求 - 清理操作可集中管理，比如页面卸载时调用
clearRegistryCache()
与业务解耦：封装成可复用的 Composable
把缓存逻辑抽离为独立函数或组合式 API，比如 useCachedGet(url, options)，让组件只关注“我要什么数据”，不关心“怎么缓存”。
- 支持传入
useCache: true、ttl: 60000等配置 - 返回值保持和普通异步函数一致：
Promise<T> - 内部自动处理 loading、error、缓存命中等状态，也可暴露缓存控制方法如
invalidate(url)
