先把页面拆成不同新鲜度的数据域
一个文章页看似只有一个地址，实际却可能同时包含已发布正文、作者资料、访客是否已点赞、待审核评论计数和实时阅读量。这些数据的所有者、隐私边界和允许陈旧时间不同，不能因为渲染在同一份页面中就共用一个缓存契约。缓存设计应先从数据域出发，然后再决定页面壳、服务端接口和客户端刷新如何组合。
对每块数据写下来源、可见人群、最长陈旧时间、变更事件和失效代价。公开且已版本化的正文可以被所有访客共享并容忍一定陈旧；会话、草稿预览、后台权限和个人操作状态必须私有且通常不缓存。评论可以独立使用短时缓存或客户端刷新。如果无法为页面中的私有字段构造完整缓存键，最稳妥的决定是不让它进入共享响应。
拆分不意味着所有区块都要变成浏览器二次请求。公开正文和可共享的分类元数据仍可服务端渲染，动态互动区块通过独立接口获取，需要首屏展示的个人状态则使用明确私有响应而非共享页面缓存。重点是使缓存边界与数据权属一致，而不是为了追求单一模式而牺牲首屏或隐私。
路由规则是响应契约而不是性能开关
为文章路由启用重新验证或服务端缓存时，实际上是在定义响应可被谁复用、可陈旧多久以及陈旧时是等待还是先返回。这个决定应进入架构评审和测试，不是在配置中随手填一个时间数字。规则必须与接口的实际响应头、边缘层行为和失效过程一起验证，否则开发者看到的配置与用户收到的内容可能不同。
路由通配符需要严格检查覆盖范围。一条针对公开文章的宽泛规则，可能意外匹配预览、编辑或带秘密标记的子路由。安全性更强的特定规则应显式覆盖缓存行为，并在测试中列出每个真实路径最终命中的策略。不要假设更长或更后声明的配置一定获胜，而应依据框架的匹配语义做契约测试。
缓存时间应来自内容发布频率和业务可容忍的陈旧，而不是越长越好。有明确发布事件与稳定版本标识的内容，可以使用长存活时间配合定向失效；无法可靠失效的内容只能使用较短上限。将失效能力、最长陈旧和回源峰值一起评估，避免在一次全站发布后同时让大量请求穿透到数据库。
公共缓存键绝不能忽略会话
只要响应中包含一个用户特定字段，这份响应就不能依赖仅有路径的公共缓存键。“我是否已点赞”、未读通知数、草稿内容和管理按钮都会把响应变成私有。不能只将用户标识加到缓存键就宣称安全，因为鉴权状态、角色和资源授权也会变化，且高基数用户键可以让公共缓存失去经济价值。更清晰的做法是将私有区块从共享内容中分离。
会话缓存若确有性能需求，应位于受控服务端并使用不可猎枚的内部主体标识、会话版本和权限上下文构造键，响应头严格禁止共享中间层存储。用户退出、禁用或会话版本递增时应使旧键自然失效。但对管理权限和高风险资源仍应优先实时鉴权，不用缓存成功的旧授权结果代替当前数据库事实。
测试公共缓存泄漏时，用两个具有不同状态的真实会话交替请求同一地址，包含无会话、普通用户、管理员和会话刚失效的组合。检查响应正文、页面负载、缓存状态头和实际源站请求数。不要只在本地开发服务器测试，因为边缘和反向代理才是发生跨用户复用的位置。测试账号中放置显眼的唯一标记，可让意外混用立即暴露。
发布失效应绑定内容版本
发布文章时可以精确知道哪个稳定标识的内容版本发生变化，因此失效应以文章标识或内容标签为目标，同时覆盖正文页、首页列表、分类列表、专题页、订阅源和站点地图等派生视图。不要为方便只清空全部缓存，那会在每次发布后制造大规模回源峰值；也不能只失效正文，否则用户会在列表和订阅源中看到相互矛盾的版本。
失效消息应在文章状态与版本交易成功后产生，并包含稳定内容标识和新版本。如果发布事务与失效通知之间可能断线，用事务内的待发事件或可重试发布日志保证不会永久遗漏。失效消费者以事件标识幂等，重复失效可以安全执行。只有发布交易真正提交后才通知缓存，避免回滚事务却已清除旧版本。
缓存内部最好直接以内容版本作为键的一部分，这样新发布请求自然不会命中旧值，定向失效主要负责清理占用空间和无版本的派生列表。列表响应可包含所有条目版本摘要作为验证标识，或使用分类内容世代号。这些取舍需要根据发布频率和列表数量选择，但共同原则是可从键解释它代表的数据版本。
动态互动使用独立不存储契约
评论、当前用户状态和管理审核信息不应被包在公开正文的服务端负载中。将它们放在独立接口，响应明确不存储，客户端在水合后获取并按各自的事件刷新。这不仅避免私有数据进入公共缓存，也让新评论或点赞无需失效整篇文章。动态区块应有独立加载与错误状态，不因辅助接口失败就隐藏已成功渲染的公开正文。
不存储必须在实际响应头中验证，不能只相信路由文件中的意图。反向代理、边缘层或平台默认规则可能覆盖应用头，必须在类生产环境用真实会话检查。带授权头或会话的响应默认应保守，错误响应也不缓存，避免一次短暂未授权或服务故障在边缘层持续提供给已恢复的用户。
客户端焦点恢复可以刷新评论与个人状态，但不应每次都重新获取长正文。为动态请求设置合理的前台新鲜度和取消语义，多个页签之间可通过轻量事件通知需要刷新，但不广播敏感正文。用户提交新评论后可先按接口返回的审核状态更新局部视图，然后重新验证评论接口，不假设公共列表已立即可见。
错误响应、条件请求与陈旧服务
一次数据库不可用或未授权响应如果被公共缓存，会在源站恢复后继续影响访客。缓存中间层应只存储明确允许的成功响应，对重定向、鉴权失败、限流和服务故障使用不存储或极为审慎的专用策略。应用不应在数据库不可用时回退到演示文章并让缓存把它变成长期内容，故障必须以可观测状态向上传播。
对可共享的正文使用稳定内容标识作为响应验证器，客户端或中间层在再验证时发送条件请求，未变更则返回无正文响应。验证器必须反映会改变表示的所有字段，包括正文、标题、封面和可见分类，不能只使用数据库某一列的更新时间。使用响应字节哈希或单调内容版本都可以，关键是可以稳定重现且不包含私有会话变量。
陈旧期间先返回旧正文、后台再验证可以降低尾延迟，但必须设置最大陈旧上限和单航班回源，避免大量同键请求一起更新。后台验证失败时是否继续服务旧值，应按内容风险决定：一篇技术博客可能允许，权限或价格数据则不应。响应头或内部指标要标明命中、陈旧服务、后台验证与回源，才能看见真正的缓存行为。
穿过应用与边缘的缓存验证矩阵
功能矩阵从内容版本开始：首次访问回源，第二次命中，发布新版后在允许时间内看到新内容，回滚发布后同样收敛。同时访问正文、首页、分类、专题、订阅源和站点地图，确认派生视图没有长期混用版本。在失效通知前后强制中断发布进程，验证事件可重试且数据库交易回滚不会将未发布版本提供给用户。
隐私矩阵用不同会话交替访问，包括两个普通用户、普通用户与管理员、登录与未登录、会话失效前后。断言个人点赞、未读数、草稿和管理元素从不跨主体出现，并检查会话响应头没有允许公共存储。再让数据库、鉴权服务和动态评论接口分别故障，确认错误响应未被缓存，公开正文的可用性又符合预先定义的降级策略。
性能矩阵不只看平均响应时间，还要观察命中率、陈旧比例、回源合并率、失效延迟和源站尾延迟。模拟热门文章同时过期、全站发布和边缘节点冷启动，检查单航班与退避能否阻止数据库峰值。所有测试都应经过与正式服务相同的反向代理和边缘策略，因为只在应用进程内测到的缓存行为不能代表用户真正收到的响应。
实现片段
routeRules: { "/articles/**": { swr: 3600 } }
评论 · 0