预览请求很多时，HTTP 缓存可以作为减轻源站压力的一项候选机制，但“页面打开更快”不足以证明服务器工作量已经下降。要分别核对响应能存在哪里、再次使用前是否仍要请求源站，以及返回的内容是否符合本次访问条件。受限文档还须先满足既有的数据处理许可，不能为了提高命中率扩大共享范围。
本文讨论的是预览响应的 HTTP 存储与复用，不是编辑并发容量或模型回答缓存。以公开协议和浏览器文档说明评估方法，不预设具体办公产品使用某种缓存。下述记录是待执行设计，未访问客户服务、改缓存配置或进行负载测试。
先确认缓存了哪一种响应
MDN 的 HTTP 缓存指南区分客户端的私有缓存与位于客户端和服务器之间的共享缓存。项目还可能采用受管反向代理、CDN 或 Service Worker；它们是否存在、保存什么、如何清理，要由实际架构回答，不能把这些组件都画成项目已有能力。
一次预览页面可能同时请求页面壳、脚本和文档内容。页面壳重复使用，并不说明正文也被复用；相反，某个正文响应绕过源站，也不能证明整次打开没有服务端成本。评估时选定具体响应及访问入口，画出真实路径，说明在哪层观察命中、请求和返回内容。
对可存储范围先取得业务与数据管理依据。允许在单个浏览器保留，与允许被中间共享缓存复用，是两种不同条件；客户端已经收到的内容也存在自己的生命周期。本文不给受限文件提供一组可以直接套用的生产响应头。
no-cache 仍可存，private 也不等于禁存
RFC 9111 的响应指令说明了几个容易混淆的含义。下表仅讨论不带字段参数的普通形式，省略特殊组合与实现扩展；它用于读懂方案，不是部署配方。
| 指令 | 协议中的重点 | 不能理解为 |
|---|---|---|
| no-cache | 允许存储，复用前须转发验证并收到成功响应 | 完全不保存，或请求永不到源站 |
| no-store | 要求私有和共享 HTTP 缓存不存储本次请求与响应，也不据此满足其他请求 | 远程召回已经存在的所有副本 |
| private | 禁止共享缓存存储，私有缓存仍可能按规则存储 | 内容加密、自动鉴权或任何位置都不保留 |
MDN 的 Cache-Control 参考页也强调了存储与复用的区别。比如要求每次复用前验证的路径，可能仍减少响应体传输，但不会凭空消除验证请求。收到 304 Not Modified 时没有新的响应体，不等于源站没有处理请求，更不能仅用这个状态证明本次文档权限判断正确。
因此，不能把“请求数下降”和“传输字节下降”合为同一指标。若主要压力来自正文生成、身份恢复或其他处理，还要观察对应工作是否实际减少；一个较小的验证响应，不能直接换算成固定比例的 CPU 节省。
Vary 解决匹配问题，不替代文档授权
Vary 参考页说明，它让缓存匹配考虑列出的请求头。例如内容协商按语言返回不同内容时，缓存需要区分相应请求条件。这种协议匹配不是企业文档的授权策略，不能把 Vary 当作租户隔离或当前访问权校验的证明。
有 Cookie 不代表响应必然只能存在私有缓存；Set-Cookie 也不会自动禁止缓存。带 Authorization 的请求，其响应在共享复用上受到 RFC 9111 第 3.5 节限制，但规范同时规定了可以改变该限制的响应指令及条件。不能简单写“登录后的响应一定不会被共享缓存”，也不能因为某个指令允许共享复用，就认定业务已经许可这样保存私人资料。
实施方需要解释的是：这份响应为什么允许被该层存储，以及复用时如何满足项目的访问要求。不能只交一张 Vary 或缓存命中截图，也不能为了减少源站请求而取消原有鉴权步骤。
内容或权限变化后，不能只等一条新响应头
缓存中的“新鲜”依据协议中的时间与条件计算，不是“当前仍有业务授权”的同义词。如果一次复用没有触达源站，服务器可能没有机会对这次访问重新作判断。因此，内容更新和授权变化后的处理，要落实到实际存在的缓存层及其失效机制。
新返回 no-store 不会清除此前已经存储的旧响应。RFC 9111 第 4.4 节对状态改变请求的失效规则，也不保证所有缓存全局同步失效；请求只经过部分缓存时，不能把一次更新操作写成全路径清理完成。受管缓存的清理能力应依据所用系统的正式机制单独验证。
还要区分新网络请求与浏览器历史恢复。MDN 明确，no-cache 不保证用户按“后退”时一定重新验证；历史页面恢复与 HTTP 缓存请求并非同一个过程。已经显示、下载或另存的内容，也不能只靠响应头保证远程召回。报告应写清检查的是哪条路径，不把其中一条通过外推到所有副本。
用四条路径报告压力，收益才可比较
在授权隔离环境中，可用合成文档，先固定文件版本、预览规格、身份条件、访问入口和到达负载，再分别观察四类路径：首次取得响应；符合规则时直接复用；需要验证但内容未变；内容变化后取得新响应。不能只把反复打开同一份文件的最好结果，与全部首次访问的基线比较。
每条路径都记录客户端尝试次数、实际到达源站的请求数、验证响应与带正文响应、传输字节，以及约定时间窗口内的延迟、失败和资源消耗。单位和观察位置要一致；看不到某层请求就标记缺口，不将其填成零。重复请求本来很少的业务，不能沿用高重复样本的命中率。
再核对返回内容及约定访问条件。若需要禁存或每次验证，评估必须包含这些实际路径的成本；不能为取得好看的缓存结果临时扩大保存或复用权限。最终将收益写成“在这组内容、访问和失效条件下减少了哪些工作”，编辑协作和文件转换容量另行核算。
评估石墨办公文档中台私有部署的预览方案时，可带上文件样本、访问路径、数据保存约束与这四类负载记录预约架构演示。请实施方说明真实缓存位置、验证和失效边界，再通过项目测试确认资源需求；本文不承诺产品缓存实现或性能提升比例。也可以先看私有化部署方案，了解部署形态与交付范围。