网站维护过程中，有一种情况反复出现：图片已经替换，部分访问者仍然看到旧版本；样式表调整过，有人打开页面却出现布局错位。检查服务器文件正常，代码也没有改动痕迹，最终定位到缓存过期时间被统一设置成了同一个数值。浏览器和中间缓存层无法判断哪些资源该优先更新，资源刷新就变成了一件不确定的事。
缓存机制本身并没有错，问题在于把更新频率不同、类型不同的资源塞进了同一套规则。静态资源至少应该区分以下几类：带哈希指纹的构建产物、不带指纹的图片、字体文件，以及接口返回的数据。
带哈希指纹的构建产物，例如文件名中包含内容摘要的脚本和样式文件，适合配置较长的缓存有效期。内容一旦变化，文件名随之改变，浏览器会将其视为全新地址发起请求，不会出现读取旧版本的情况。这类文件可以放心使用较长的过期时间，降低重复下载。
不带指纹的图片需要更谨慎地处理。同一路径下的图片随时可能被替换，如果缓存时间设置过长，用户会长期停留在旧图上。比较稳妥的方式是给它配置较短的缓存时间，或者在替换图片时同步修改文件名或路径，让地址本身发生变化。
字体文件更新频率很低，体积又相对较大，适合设置较长的缓存时间。但需要注意跨域场景下相关响应头是否配置完整，否则字体可能因为权限问题加载失败，表现出来却是样式异常。
接口返回的数据不属于静态资源，不应该套用静态文件的缓存规则。这类内容通常需要更短的有效期，或者通过请求头控制是否走缓存，避免用户看到过期数据。
梳理清楚分类之后，可以用一份检查清单来对照现有配置。第一，确认每类资源都有明确的缓存头字段，而不是依赖默认行为。第二，检查带指纹的文件是否真的做到了内容变化即文件名变化。第三，确认不带指纹的图片和样式有合理的短缓存或改名机制。第四，明确缓存刷新方式，是等待自然过期，还是通过改名、改路径主动失效。第五，准备好回退手段，一旦新配置导致异常，能快速恢复到之前的策略。
调整缓存策略之后，不能只看配置文件就认为完成。验证环节同样重要。可以先用浏览器开发者工具查看具体资源的响应头，确认过期时间和缓存标识符合预期。再模拟一次资源更新，观察页面是否能在合理时间内加载到新版本。有条件的话，换一个没有访问过的环境重新打开页面，避免本地缓存干扰判断。最后，把关键页面的样式和脚本做一次回归检查，确认没有因为缓存变化导致加载顺序或依赖关系出错。
缓存策略不是设定一次就能长期不管的配置。构建方式变了，文件命名规则变了，资源类型增加了，原来的过期时间就可能不再合适。把它当成维护清单里的一个固定复核项，随版本迭代定期回看，才能让更新这件事变得可预期。it数运在网站维护服务中，也把这类配置复核纳入日常检查范围，目的是让交付之后的运行状态保持清晰可控。技术有章法，服务有回应，靠的正是这些看起来琐碎却影响体验的细节。
