当讨论网站性能优化时，服务器端缓存往往是最先被提及的手段。它通过把频繁访问的内容副本放在离用户更近的位置，减少源站负载并缩短响应时间。但“服务器端缓存”并非单一技术，它涵盖 CDN 边缘缓存、反向代理缓存、对象缓存、边缘 KV 存储等多个层次。选择哪种方案，取决于你的网站架构、内容类型和流量特征。本文先厘清各类缓存的边界，再给出可执行的比较与选择路径。
先明确：服务器端缓存的四种常见形态
服务器端缓存通常以四种形态存在，它们的存储位置、失效粒度和适用场景各不相同。
- 源站缓存（如 Redis、Memcached）：部署在应用服务器或独立缓存服务器上，缓存数据库查询结果、会话数据或渲染片段。适合动态内容，但受限于源站地理位置，无法缩短全球用户的网络延迟。
- CDN 边缘缓存：将静态资源（图片、CSS、JS）或整页 HTML 缓存在全球分布的边缘节点。用户就近获取，显著降低源站压力和回源流量。Cloudflare 的 CDN 即属此类。
- 边缘 KV 存储（如 Cloudflare Workers KV）：一种全球复制的键值存储，读取延迟低，适合存储配置、A/B 测试标志等小数据，但写入有传播延迟。
- 反向代理缓存（如 Varnish、Nginx）：位于应用服务器前，缓存动态页面的完整响应。适合中大型网站，可精细控制缓存规则。
理解这些形态后，选择的关键在于：你的内容是静态为主还是动态为主？用户分布是否全球化？缓存失效的实时性要求有多高？
CDN 边缘缓存：静态内容的首选
如果你的网站包含大量图片、视频、CSS/JS 文件，CDN 边缘缓存是最直接的性能提升手段。Cloudflare 官方文档指出，其 CDN 会在全球分布式数据中心存储频繁访问的内容副本，这些数据中心比源站更靠近终端用户，从而减少服务器负载并提升性能。
配置 CDN 缓存时，需要关注三个核心参数：
- 缓存规则（Cache Rules）：指定哪些资源应被缓存以及缓存时长。例如，对 /static/* 路径设置 30 天缓存，对 HTML 页面设置 5 分钟。
- 缓存级别：默认缓存静态文件扩展名（如 .jpg、.css），但动态 URL 默认不缓存。可通过规则覆盖。
- 缓存响应头：源站返回的 Cache-Control 和 Expires 头会直接影响 CDN 行为。务必确保源站正确设置。
一个常见误区是“只要用了 CDN，所有内容都会被缓存”。实际上，如果源站返回的响应头不允许缓存（如 Cache-Control: private），CDN 会遵循该指令。因此，配置 CDN 的同时，必须审视源站的缓存头。
边缘 KV 存储：动态数据的低延迟读取
对于需要快速读取但更新不频繁的数据（如产品目录、用户偏好设置），Cloudflare Workers KV 提供了低延迟的键值存储。它基于边缘缓存，读取速度极快，适合在 Worker 中调用。
但要注意，KV 的写入是异步的，全球传播可能需要数十秒。因此，它不适合频繁更新的数据，例如购物车会话或实时计数器。对于这类场景，应使用 Durable Objects 或数据库。
在网站性能优化中，KV 的典型用途是缓存 API 响应或渲染片段。例如，在 Worker 中先查询 KV，若未命中再回源获取并写入 KV。这种模式能显著减少源站压力，但需要设计合理的过期策略。
动态内容缓存：从全页缓存到片段缓存
动态页面（如个性化首页、登录后页面）通常无法整页缓存。此时可考虑以下策略：
- 片段缓存：只缓存页面中不随用户变化的片段（如页头、页脚、推荐列表），通过 ESI（Edge Side Includes）或组件级缓存实现。
- 对象缓存：在源站使用 Redis 缓存数据库查询结果，减少重复查询。这属于源站缓存，但能显著提升动态页面的生成速度。
- 边缘计算：使用 Cloudflare Workers 在边缘生成动态内容，结合 KV 或 D1 数据库，将动态逻辑推到离用户更近的位置。
选择动态内容缓存方案时，需要评估：动态内容的个性化程度有多高？实时性要求如何？如果允许秒级延迟，边缘 KV 是不错的选择；如果需要实时一致，则只能依赖源站缓存。
缓存失效与一致性：最容易踩的坑
缓存方案的核心难点在于失效。任何缓存都会面临“数据过期”问题，处理不当会导致用户看到陈旧内容。
CDN 缓存支持主动清除（Purge）。Cloudflare 允许即时清除缓存文件，可单独清除某个 URL 或全部清除。但清除操作并非瞬时全球生效，通常需要几十秒。因此，对于更新频繁的内容，应设置较短的 TTL（如 60 秒），而不是依赖手动清除。
对于 KV 存储，写入后需要等待传播。如果你在写入后立即读取，可能拿到旧值。设计时需考虑这种最终一致性，或者使用版本号机制。
另一个常见误区是“缓存时间越长越好”。过长的 TTL 会降低更新灵活性，一旦内容变更，用户可能长时间看到旧版本。建议根据内容更新频率设置 TTL，并利用 Cache-Control 的 max-age 和 s-maxage 精细控制。
如何选择：一个决策框架
基于以上分析，可以按以下步骤选择服务器端缓存方案：
- 分析内容类型：静态资源（图片、CSS/JS）→ CDN 边缘缓存；动态 HTML → 视个性化程度选择片段缓存或边缘渲染；API 响应 → 边缘 KV 或源站对象缓存。
- 评估用户分布：如果用户遍布全球，优先选择具有全球节点的 CDN 和边缘 KV；如果主要在一个区域，源站缓存加本地 CDN 可能足够。
- 确定一致性要求：实时性要求高 → 避免边缘 KV，使用源站缓存或数据库；允许最终一致 → 边缘 KV 和 CDN 都可行。
- 考虑运维成本：CDN 配置简单，但需要理解缓存头；Workers KV 需要编写代码，但灵活度高；源站缓存需要维护缓存服务器。
例如，一个静态内容为主的博客，使用 CDN 缓存即可大幅提升性能；而一个电商网站，可能需要 CDN 缓存静态资源 + 边缘 KV 缓存商品信息 + 源站 Redis 缓存会话数据，组合使用。
结合压缩：缓存与压缩的协同
服务器端缓存与内容压缩是相辅相成的。缓存可以减少传输次数，而压缩可以减小每个响应的体积。Cloudflare 的 CDN 支持在边缘压缩内容（如 Brotli 或 Gzip），进一步降低带宽消耗。
在配置缓存时，应确保压缩后的内容也能被正确缓存。通常，CDN 会根据 Accept-Encoding 请求头缓存不同压缩版本的副本。如果源站已启用压缩，可参考本站关于 Brotli 压缩的实践，避免重复压缩。
压缩与缓存的协同能显著提升加载速度，但要注意：压缩对 CPU 有轻微消耗，对于高并发场景，边缘压缩可能比源站压缩更合适。
常见误区与失败条件
- 误区一：缓存所有内容：导致动态内容被错误缓存，用户看到他人数据。必须严格区分可缓存与不可缓存。
- 误区二：忽略缓存头：源站未设置 Cache-Control，导致 CDN 无法判断缓存时长，默认不缓存或缓存过短。
- 误区三：缓存键设计不当：未包含用户标识或语言参数，导致不同用户拿到相同内容。应使用 Cache Key 区分。
- 失败条件：当源站响应包含 Set-Cookie 或 Authorization 头时，CDN 通常默认不缓存。如果必须缓存，需谨慎处理隐私。
参考资料
延伸阅读