网站已经重新部署，服务器上的 CSS 和 JavaScript 也确认替换了，但打开页面以后，部分用户还是看到旧样式，甚至不同设备看到的页面版本还不一样。
这类问题在企业网站建设和后续维护中并不少见。真正需要排查的不是“有没有清缓存”这一句话，而是先确认旧内容到底停留在哪一层，再决定应该修改浏览器缓存、服务器配置还是静态资源版本策略。
下面以 Nginx 1.24.x + 普通前端静态站点作为示例环境。实际项目中的服务器版本、目录和构建方式不同，应以当前运行环境为准。
一、先确认旧的是 HTML，还是 CSS、JavaScript
页面看起来没有更新，并不代表整个页面都来自缓存。
常见情况是：
HTML 已经是新版，但 HTML 引用的 CSS 还是旧文件；
CSS 已经更新，但浏览器继续使用旧 JavaScript；
首页已经变化，某张图片仍然来自旧缓存；
服务器内容正确，但浏览器没有重新请求资源。
排查时可以打开浏览器开发者工具，在 Network 中重新加载页面。
重点观察几个信息：
请求的文件地址；
状态码；
Response Headers；
Cache-Control；
Expires；
资源是不是来自 memory cache 或 disk cache。
如果 HTML 已经发生变化，而某个 CSS 文件仍然没有重新请求，就应该重点检查静态资源缓存，而不是继续修改页面代码。
二、不要让入口 HTML 长时间缓存
对于普通前端站点，index.html 通常承担“告诉浏览器当前应该加载哪些资源”的作用。
如果入口 HTML 被浏览器缓存很久，即使服务器已经生成了新的 JavaScript 文件，客户端仍可能继续按照旧 HTML 去加载旧文件。
可以针对入口页面设置较短缓存或要求重新验证。
例如 Nginx 中可以根据实际目录配置：
location = /index.html {
add_header Cache-Control "no-cache";
}
这里的思路不是让网站所有文件全部禁用缓存。
HTML 更新频率较高，而且它负责引用当前静态资源，因此更适合让客户端及时确认服务器是否存在新版本。
三、CSS 和 JavaScript 更适合使用版本化文件名
如果 CSS 文件一直叫：
style.css
每次部署都只是覆盖同一个文件，浏览器就需要依赖缓存时间判断什么时候重新请求。
更稳定的方式，是构建时给文件名加入内容版本标识，例如：
style.a81d3f.css
app.72f06c.js
文件内容发生变化以后，生成的新文件名也随之变化。
新版 HTML 引用：
style.a81d3f.css
下次构建后可能变成：
style.b17e42.css
浏览器看到的是新的资源地址，自然会重新请求，而不需要猜测旧缓存什么时候失效。
这也是网站前端部署中比较常见的缓存处理思路。
四、带版本号的静态资源可以使用较长缓存
当文件名已经根据内容变化时，静态资源就可以采用相对较长的缓存时间。
例如项目把构建后的资源统一放在 /assets/ 目录中，可以根据实际需要配置：
location /assets/ {
expires 30d;
add_header Cache-Control "public";
}
需要注意一个前提：
这个目录中的文件应采用版本化或哈希文件名。
如果仍然长期使用固定的 app.js、style.css，却同时设置较长缓存，新版本发布以后仍可能出现用户继续使用旧文件的问题。
所以缓存时间与文件命名方式需要一起考虑，不能只修改其中一项。
五、检查服务器返回的缓存响应头
修改 Nginx 以后，不要只看配置文件。
可以直接检查服务器实际返回的响应头。
例如：
curl -I https://example.test/index.html
再检查静态资源：
curl -I https://example.test/assets/app.a81d3f.js
重点查看：
Cache-Control
Expires
ETag
Last-Modified
这样能够确认真正返回给客户端的配置，而不是只根据服务器配置文件推测结果。
如果前面还有 CDN、反向代理或其他缓存层，还需要继续判断响应头有没有在中间环节被修改。
六、不要把“强制刷新”当成正式解决办法
开发阶段经常使用 Ctrl + F5 或浏览器“清除缓存并硬性重新加载”。
这种方法适合验证问题，但不适合作为上线后的解决方案。
用户不应该每次网站更新后都手动清理浏览器。
如果只有清缓存以后新版页面才能正常显示，说明缓存策略本身还有调整空间。
更合理的目标是：
入口页面能够及时发现新版本；
版本化静态资源可以放心缓存；
内容变化后资源地址自动变化；
普通访问者无需额外操作。
七、如果使用 Service Worker，还要多检查一层
部分网站使用 PWA 或 Service Worker 缓存资源。
这种情况下，即使浏览器普通缓存已经处理正确，Service Worker 仍可能返回自己保存的旧内容。
可以在开发者工具的 Application → Service Workers 中查看当前注册状态。
同时检查 Cache Storage 中是否仍存在旧资源。
如果网站本身并不需要离线能力，却保留了历史 Service Worker，也可能造成版本更新行为变得难以判断。
所以排查缓存时，要先弄清当前网站到底有哪些缓存层，而不是一看到旧页面就直接删除服务器文件。
八、部署后的验证流程
完成配置后，可以用一个简单流程验证。
修改一处测试用的 CSS 或 JavaScript 内容。
重新构建并部署。
确认新资源生成了新的文件名。
检查新版 index.html 是否引用新的文件。
用 curl 检查 HTML 与静态资源响应头。
使用没有访问过该版本的浏览器窗口重新打开网站。
在 Network 中确认新资源确实发起请求并正常返回。
如果 HTML 能及时更新，新静态文件能够被加载，而旧文件即使仍保留在客户端缓存中也已经不再被新页面引用，说明整个更新链路基本正常。
九、网站建设阶段就应该规划缓存策略
缓存本身并不是问题。
合理缓存能够减少重复请求、降低资源传输量，也有助于改善重复访问时的加载体验。
真正容易出问题的是：
HTML 与静态资源使用同一套缓存时间；
固定文件名长期覆盖；
部署过程没有版本标识；
多个缓存层之间没有明确关系。
因此，在武汉企业网站建设中，前端发布流程可以从一开始就把“HTML及时更新 + 静态资源版本化 + 合理长期缓存”作为一个整体处理。
这样网站后续更新页面样式、脚本和功能时，不需要反复依赖用户清理缓存，也更容易定位到底是哪一层没有获取到新版内容。
结果验证
验证时应确认：入口 HTML 返回当前版本；新版 HTML 引用了新的静态资源文件名；浏览器能够请求新资源；页面重新打开后无需手动清缓存即可显示更新后的内容。
经验总结
缓存排查的重点不是把所有缓存全部关闭，而是确定哪些内容需要及时更新、哪些资源可以长期复用。入口文件与版本化静态资源采用不同策略，通常比简单设置统一缓存时间更容易维护。
本文由梓彤超越（武汉）科技有限公司整理。
