缓存中间件在SSR中核心作用是避免重复耗时操作，主要缓存数据获取层（如DB/API），其次谨慎缓存HTML字符串，并配合HTTP缓存头协同CDN，同时需规避自身性能瓶颈。
在服务器端渲染（SSR）中，缓存中间件的核心作用是避免重复执行耗时操作——比如数据获取、模板编译和HTML生成。它不缓存最终的HTML字符串本身（除非显式配置），而是缓存“渲染前的关键依赖”，从而让后续相同请求跳过昂贵步骤，直接组装响应。
缓存数据获取层（最常用且高效）
SSR 中最大瓶颈通常来自数据库查询或外部 API 调用。用缓存中间件包裹这些操作，能显著减少 I/O 延迟：
- 使用 Redis 或内存缓存（如 node-cache） 存储序列化的响应数据，键可基于请求路径 + 查询参数生成
- 在
getServerSideProps（Next.js）或 Express 路由处理函数中，先查缓存；命中则直接返回解析后的数据，跳过 fetch - 设置合理 TTL（如 60 秒），兼顾实时性与性能；对强一致性要求高的接口，可配合缓存失效策略（如更新后主动 del）
缓存渲染结果（需谨慎使用）
对静态内容占比高、更新频率低的 SSR 页面（如活动页、详情页），可缓存完整 HTML 字符串：
- 用中间件拦截响应流，在
res.end()前捕获 HTML 并存入 Redis，键为 URL + 用户身份标识（若需个性化） - 下次请求时，若缓存存在且未过期，直接
res.send(cachedHtml)，完全绕过 React 渲染流程 - 注意：必须排除含用户态（如登录态、购物车）的页面，或对个性化部分做客户端水合（hydration）补全
利用 HTTP 缓存头协同 CDN
服务端缓存只是第一层，配合标准 HTTP 头能让边缘节点（如 Vercel Edge、Cloudflare）复用响应：
立即学习“Java免费学习笔记（深入）”；
- 对 SSR 页面响应设置
Cache-Control: public, max-age=60, stale-while-revalidate=300 - 这样 CDN 在 60 秒内直接返回缓存，过期后仍可先返回旧版本，同时后台异步刷新
- 搭配
ETag或Last-Modified实现协商缓存，降低带宽消耗
避免中间件自身成为瓶颈
缓存中间件若设计不当，反而拖慢请求：
- 不要在每个请求里新建 Redis 客户端连接，应复用全局实例
- 缓存读写操作设超时（如 10ms），失败时降级为直通，不阻塞主流程
- 对高频但低价值的请求（如健康检查），用
skip逻辑绕过缓存逻辑，减少不必要的判断开销
