什么场景下需要缓存？｜美团前端面经解析

60 秒回答模板

缓存适合结果可复用、生成成本高、变化频率低、短时间重复访问多、允许一定时效性的场景。前端常见缓存包括 HTTP 静态资源缓存、接口响应缓存、内存缓存、localStorage 或 IndexedDB 本地缓存、计算结果缓存、组件渲染缓存和媒体资源缓存。设计时要先确定缓存 key，把用户、权限、参数、版本、语言和环境都纳入影响结果的因素；再确定 TTL、主动失效、容量淘汰和降级策略。缓存的最大风险是脏数据和一致性问题，所以不能只说加缓存，还要说什么时候不用、如何刷新和如何观测命中率。

考点 核心机制与工程取舍

难度 中高频面试题

回答目标 按定义、机制、场景讲清楚

深入解析

先判断是否值得缓存

缓存是空间换时间，适合读多写少、结果稳定、重复访问、计算或请求成本高的场景。不适合强实时、权限敏感、结果高度个性化且变化频繁的场景。

缓存层级

静态资源用 HTTP 缓存和 CDN；接口数据可以用内存、请求库缓存或业务 store；离线和大数据用 IndexedDB；简单偏好配置可用 localStorage；计算结果用 memoization；组件渲染可用框架级缓存或局部记忆化。

缓存 key 设计

key 必须覆盖所有影响结果的因素，例如 URL、query、body 摘要、用户 id、租户、权限、语言、版本、AB 分桶和环境。key 不完整会导致串用户、串权限或展示错误数据。

失效策略

常见策略有 TTL、版本号、ETag/Last-Modified、主动清理、写操作后失效、后台刷新、stale-while-revalidate 和容量 LRU。失效策略要和业务一致性要求匹配。

安全和隐私边界

敏感数据不应随意放 localStorage，尤其是 token、身份证、简历、支付信息等。缓存要考虑退出登录清理、账号切换隔离、加密不能替代权限控制。

效果评估

缓存要看命中率、节省耗时、错误率、脏数据反馈、内存占用和存储容量。命中率低或导致一致性问题的缓存，应当删除或缩小范围。

易错点

把缓存当万能优化，不判断读写频率、时效性和命中率。
缓存 key 漏掉用户、权限、语言或版本，造成串数据。
只写入缓存，不设计 TTL、主动失效和容量淘汰。
把敏感信息长期放在 localStorage，退出登录或账号切换不清理。

面试官追问

接口缓存的 key 怎么设计？

至少包括请求方法、URL、query、body 摘要和用户上下文；如果权限、语言、租户、版本会影响结果，也必须纳入 key。

localStorage 和 IndexedDB 怎么选？

localStorage 适合小量字符串配置且同步 API 简单；IndexedDB 适合结构化、大容量、离线数据和异步读写。敏感数据都要谨慎。

缓存和数据一致性怎么平衡？

按业务时效要求选择 TTL、主动失效、后台刷新或强制重新请求。写操作成功后要失效或更新相关缓存，不能只等自然过期。

什么场景不建议缓存？

强实时数据、权限变化频繁、隐私敏感、结果一次性使用、命中率低或参数组合爆炸的场景，不适合无脑缓存。