资源没有 Cache-Control 响应头，不能直接写成“网站完全没有缓存”。它说明这次没有观察到该资源明确提供这项缓存指令，仍需继续看验证信息和实际重复请求。缓存审计最有用的结果是说清哪些行为已证实、哪些策略未明确，而不是只凭一个字段把全站归零。
先把缓存头当成不同职责的线索
Cache-Control 用于声明缓存相关策略，ETag 则是资源版本验证信息，Last-Modified 表示修改时间信息。它们不是互相替代的同一个字段。有 ETag 不意味着已经设置了适合所有资源的长期缓存；没有 Cache-Control 也不意味着浏览器绝对不会复用内容。
MDN 的 HTTP 缓存说明指出，缺少明确控制时可能存在启发式缓存。具体行为还需要结合响应与实际请求检查。因此审计报告应描述观察结果，不把字段缺失扩张成所有缓存层均不存在。
JVDS 2026年10月2日的检测中，部分静态资源的请求未见明确 Cache-Control，同时观察到了 ETag 或 Last-Modified。这是当时样本的响应事实。它支持进一步核对缓存策略，不支持宣称网站没有任何缓存，也不证明当前全部资源拥有同样行为。
用两个问题区分复用和验证
第一个问题是：下一次访问时，浏览器是否能直接使用已有内容？第二个问题是：如果需要联系服务器，能否确认已有内容仍是当前版本？前者关注是否重新请求，后者关注如何验证版本。
条件请求得到304响应时，通常意味着服务器通知客户端已有版本仍可使用，并未重新发送完整正文。这与完全不发出请求是不同情况，也与重新收到整份文件不同。MDN 的 ETag 说明可以帮助理解它作为版本标识的用途。
假设一张图片再次访问时产生验证请求，返回304，不宜写“每次都重新下载整张图”；也不宜写“没有任何网络请求”。如果报告只展示缓存字段，却不看这次的请求结果，就容易把不同状态混成一种。
运营不需要熟悉所有协议细节，但应要求报告用普通话说明：这项样本直接复用了什么、向服务器验证了什么、重新获取了什么。具体工具中的字段名称保留为证据，文字结论则解释它们与当前任务的关系。
先给被测资源分组，别只检查首页
网页正文、图片、样式、脚本与下载文件的更新需求不同。文章正文可能刚刚编辑，带版本路径的静态文件可能很少变化，后台页面又涉及不同的使用场景。将一张图片的结果推广到整站，会掩盖这些差别。相关操作可参阅《网页图片怎么做响应式？别再让手机加载一张3000px大图》。
建议先挑有代表性的公开资源：一篇正文页面、一张案例图、一个样式文件、一个脚本文件。记录网址、类型、修改方式和期望更新行为。涉及管理后台或个人内容时，应由维护者按相应条件检查，不能照搬公开图片策略。
如果资源来自不同域名或服务，也应分别记录。主站和外部资源不一定经过同一套规则。某个外部文件的缓存表现，不能直接归因于主站服务器设置。
分组后的成功标志是每项结论都能指出具体样本。报告可以说“该次静态图片样本有验证标识，明确策略待核对”，而不是一句“缓存异常”。读者知道对象后，才能判断优先处理哪些资源。
重复请求测试怎样避免误读
第一次检查时保留响应头与实际获得的资源。第二次在明确条件下重复访问，观察是否请求、返回什么状态以及是否重新获取内容。第三次在资源更新后复查，确认预期版本能被看到。每次都记录浏览器和测试方式。
某些测试设置会改变缓存使用方式，开发工具中主动禁用缓存也会影响观察。因此测试者应说明是否开启了这类选项。不能一边禁用缓存，一边根据重复下载指责正式策略完全无效。相关操作可参阅《企业网站上线流程：域名、服务器、证书、缓存与验证清单》。
测试前也要确定是否存在中间服务。浏览器可能从本地复用，代理服务可能保存副本，源服务器可能设置另一层规则。运营报告不用列出私有配置，但维护者需要说明当前证据反映了哪一层，哪些层没有核对。
如果仅用一次请求头检查，不能还原完整浏览器行为。可以把它写成初步响应检查，并另列重复访问待测。单次结果依然有价值，但价值在于提供线索，不是替代全部验证。
为方便复查，可以让每个样本带上一项内容识别点。例如图片主体和裁切，样式中的具体布局，文章开头的一句已确认文字。它们帮助判断取得的是哪个版本，避免只看到文件能返回，就把更新验收也记作通过。
如果工具显示“来自缓存”，仍应保存具体表现而不要推断所有层。这个标签可能对应浏览器本地资源获取状态，无法替代中间服务的核对。维护者可以在内部补充更完整的路径，运营交接只需说明哪些结果已经确认。
还要避免把资源体积和缓存效果混为一谈。同一个文件仍然很大，但重复访问不一定再次传输全部内容；一个很小的文件也可能被不断请求。体积检查和缓存检查可以相互补充，却应使用不同字段，便于判断优化方向。
面向多人编辑的站点，更新测试最好包括运营真实的保存方式。后台替换图片、发布新正文与开发更新静态文件可能经过不同路径。只验证开发者自己上传的一份样本，不能确认日常内容更新也同样可靠。成功标志是测试操作与实际工作一致，并能观察到预期版本。
长缓存是否合适，要看更新路径
对缓存策略的建议不能只有“时间越长越好”。如果一个资源修改后仍使用相同网址，较长复用可能影响新版本出现的时间；如果有可靠的版本路径或文件名机制，更新安排又不同。应先确认网站实际如何发布新文件。
假设运营直接覆盖一张同名封面，浏览器仍显示旧图，问题需要同时核对上传是否成功、页面引用是否正确、缓存行为与更新方法。不能未检查就要求全站清空，也不能只让运营多刷新几次就算完成。
文章与静态资源也不宜统一处理。公开页面是否有动态内容、数据是否频繁变化、修改后需要多快可见，都影响策略选择。涉及访问者信息的内容，应由维护者结合实际处理方式制定，不因某个图片建议而批量修改。
验收目标可以写成“未更新资源重复访问有合理复用，更新后按约定方式获取新版本”。这里的合理与时限需在项目中明确，不能让一个含糊的“缓存已优化”代替更新检查。
审计报告应交付可执行的表达
把发现分成事实、解释和建议三行。事实写这次样本看到了什么，例如有版本验证字段、未观察到明确控制头。解释说明目前能判断什么，以及单次请求不能判断的部分。建议给出待补测试和资源分组，而不是直接宣布根因。
若重复访问已经证实没有重新发送完整内容，可以记录该行为，但仍不要写“所有用户永远不会下载”。若更新后观察到了旧版本，应保存具体文件和时间，继续排查发布与复用过程。
改动前后使用同一组样本，保留测试条件，核对版本显示与业务操作。成功标志不仅是新增一个响应头，还包括它对应的行为符合要求。只看字段出现，可能遗漏策略取值不适合或更新仍受影响。
对于未覆盖的资源和层级，直写待确认。缓存审计的可信度来自结论不越过证据，以及修改能够按相同方法复查。这样报告既不会把一个字段缺失夸大成整站问题，也不会因为看到 ETag 就提前宣布优化完成。
常见问题
有 ETag 就不用设置其他缓存规则了吗？
不能这样理解。版本验证与明确复用策略职责不同。是否需要调整，应结合资源类型、更新方式与重复访问结果，由维护者制定。
304是否表示图片没有加载？
通常是验证已有资源仍可使用，不等于图片缺失。需要结合浏览器是否已有对应内容和页面实际显示检查，而不是只看状态数字。
手动刷新看到新图，其他访客也一定看到吗？
不能从一个人的一次操作推广。测试条件与缓存状态可能不同，应按约定更新方式，在代表性场景复查并记录范围。
可以让所有文件使用同一缓存时间吗？
需先区分资源与更新需求。公开静态图、频繁编辑正文和后台页面不一定适合同一规则，统一配置前应确认实际使用条件。
发现缺头，应该马上修改服务器吗？
先确认被测对象与已有行为。报告可以提出核对需求，但不要仅凭一次字段检查改全站策略。修改后还需验证复用和新版本更新都符合约定。
链接复制成功
