电商商品列表缓存优化：兼顾缓存收益与用户购买状态准确性

针对你遇到的缓存静态页面但需动态展示用户购买状态按钮的问题，分享几个实际生产环境中验证过的方案：

方案1：静态内容全缓存 + 前端异步批量获取状态 #

• 核心逻辑：将商品列表的**静态内容（商品图、名称、价格、描述等）**做全量缓存（30分钟），页面中的按钮位置先渲染为默认的"buy"。页面加载完成后，前端收集当前页面所有商品的ID，发起一次批量请求到后端接口（如POST /api/user/purchased-status，参数为user_id和sku_ids数组），后端返回每个商品的购买状态，前端再批量替换对应按钮的文本为"bought"。
• 优势：完全复用原有缓存逻辑，无需修改后端缓存策略；单批量请求性能开销极低，不会对服务器造成压力。
• 注意事项：
  • 后端接口需优化批量查询逻辑，用IN语句或Redis集合查询，避免N+1数据库请求；
  • 前端要处理请求失败的降级逻辑（比如保持"buy"按钮不变）；
  • 可给按钮加加载状态，避免用户误解。

方案2：后端缓存占位符 + 实时替换 #

• 核心逻辑：缓存页面时，将所有按钮替换为占位符（如{{buy_btn_sku_12345}}）。当用户请求页面时，后端先取出缓存的页面内容，再通过快速查询（比如从Redis中读取用户已购商品ID集合）获取当前用户的已购状态，最后批量替换页面中的所有占位符为对应的"buy"或"bought"按钮HTML。
• 优势：前端拿到的是最终渲染完成的页面，无需额外前端逻辑，用户体验更流畅；缓存复用率依然很高，替换操作的性能开销可以忽略。
• 注意事项：
  • 用Redis存储用户已购商品ID的集合（user:purchased:123），支持O(1)时间复杂度的成员查询；
  • 字符串替换操作要高效，避免正则表达式的过度使用，可提前生成替换映射表后批量替换。

方案3：用户分组差异化缓存 #

• 核心逻辑：将用户分为两类：未购买过任何商品的新用户和已购买过商品的老用户。
  • 新用户直接使用全量缓存页面（所有按钮都是"buy"）；
  • 老用户则在请求时，后端先取出全量缓存，再结合用户的已购状态做按钮替换（逻辑同方案2），或者针对老用户生成带状态的缓存（缓存键包含用户ID或用户分组标识，注意控制缓存数量，避免缓存爆炸）。
• 优势：大部分新用户可以直接复用缓存，老用户的处理成本可控，平衡缓存收益和动态需求。
• 注意事项：要通过用户的购买记录快速判断分组，比如用Redis标记用户是否为已购用户，避免每次都查询数据库。

方案4：客户端本地存储辅助优化 #

• 核心逻辑：用户成功购买商品后，前端将该商品ID存入localStorage或sessionStorage中。当页面加载时，先从本地存储读取已购商品ID，立即替换对应按钮为"bought"；同时异步发起后端请求校验状态，若本地存储与后端状态不一致（比如用户在其他设备购买），则更新本地存储并修正按钮状态。
• 优势：前端可以瞬间更新按钮状态，无需等待后端响应，体验极佳；同时减少后端接口的请求量，降低服务器压力。
• 注意事项：必须加后端校验的异步逻辑，避免本地存储状态过期或不一致导致的错误展示；本地存储的键要区分用户，比如加上用户ID前缀，避免多用户共用设备时的状态混淆。

内容的提问来源于stack exchange，提问作者Hossein Jalali