企业官网建设流程全解析

1. 先搞清楚：http缓存到底在解决什么问题

做Web开发这些年，http缓存是我接手任何一个项目后最先检查的东西。原因很简单：http缓存是浏览器与服务器之间用HTTP协议头控制的资源复用机制，它的核心价值就是让“重复的事情不重复做”。一个首页动辄几十个请求，JS、CSS、图片、字体、接口数据，如果没有缓存，每次访问都把整站资源重新下载一遍，页面打开速度直接慢一个数量级。有了缓存，第二次打开几乎秒开，带宽压力也大幅下降。

这个主题适合谁来读？前端工程师、后端开发、部署运维、以及所有对Web性能优化感兴趣的人都应该看一下。尤其是“页面改完代码，用户那边却还是旧版本”这种问题，几乎每个人都会遇到，而根因几乎都出在http缓存配置上。这篇内容我尽量用大白话讲，把缓存机制的底层逻辑、实际配置方法、踩坑经验一次说透。文中所有实操方案都是我实际用过的，配置模板可以直接抄，但更重要的是理解它为什么这么配，因为不同项目的缓存策略差异很大，抄作业要抄懂逻辑，而不是照搬命令。

2. 强制缓存与协商缓存：两个核心机制的底层逻辑

2.1 强制缓存：浏览器怎么“自作主张”不走网络

强制缓存的意思很好理解：浏览器在本地存了一份资源副本，在有效期之内直接使用，根本不会发出网络请求。

有两个头字段负责这件事：一个是老的Expires，一个是现在的Cache-Control。Expires是服务器返回的一个绝对时间点，比如Expires: Thu, 01 Jan 2026 00:00:00 GMT，浏览器判断当前时间是否超过这个时间点，没超过就用缓存。问题在于它依赖客户端本地时间，用户电脑时间如果不准，缓存就会乱套。所以现在主流方案是Cache-Control，它用相对时间max-age，单位是秒，比如Cache-Control: max-age=31536000表示资源在一年内有效，浏览器从收到响应的那一刻开始计时，完全不依赖客户端时钟，比Expires靠谱得多。

很多初学者会混淆no-cache和no-store这两个值，这里重点讲一下：

• no-cache：不是不缓存，而是“可以使用缓存，但使用前必须回服务器确认”。它实际上把强制缓存降级为协商缓存。
• no-store：才是真正的禁止缓存，每次都从服务器拉取完整资源。
• public：允许浏览器和中间代理（比如CDN）缓存。
• private：只允许浏览器缓存，不允许CDN等中间节点缓存。

如果Expires和Cache-Control同时存在，浏览器以Cache-Control为准。

举个例子方便理解：强制缓存就像你自己家里有一个冰箱，食材放进去在保质期内直接拿出来做菜，不用再去超市跑一趟。而max-age就是你在冰箱上贴的保质期标签，到期之前自动信任。

2.2 协商缓存：浏览器怎么“礼貌地问”服务器

强制缓存过期了，不代表这个资源就一定变了。协商缓存就是解决这个“不确定”的方案：浏览器带着资源的身份信息去问服务器“这东西还是原来的吗？”，服务器如果确认没变，只返回一个很小的304状态码，不返回资源内容，浏览器收到后继续用本地副本。这个过程的网络开销极小，但能确保浏览器拿到的一定是最新资源。

协商缓存有两对头字段：

第一对是Last-Modified和If-Modified-Since。服务器第一次返回资源时，会在响应头里带上Last-Modified，也就是文件的最后修改时间。浏览器再次请求时，在请求头里带上If-Modified-Since，值就是之前的Last-Modified。服务器拿这个时间和文件实际的最后修改时间比较，如果一致就返回304。

第二对是ETag和If-None-Match。ETag是服务器根据资源内容生成的一段唯一标识，类似于内容的“指纹”，通常是对文件内容做哈希得到的字符串。浏览器再次请求时带上If-None-Match，值就是之前的ETag，服务器重新计算资源的ETag和它比较，一致则返回304。

为什么要搞出两套验证机制？因为Last-Modified有两个明显的缺陷：第一，它的精度只有秒级，如果一个文件在1秒内被修改了多次，最后修改时间完全看不出变化；第二，某些情况下文件内容变了但修改时间没变（比如服务器端手动改回旧版本文件）。ETag基于内容生成，能精确感知任何字节的变化，可靠得多。所以实际生产环境中，我建议优先信任ETag，把Last-Modified当成辅助手段。

2.3 两者的配合：为什么说协商是强制的兜底

强制缓存和协商缓存不是互斥关系，而是一条完整的递进链路。资源第一次返回时，响应头里通常同时带上Cache-Control: max-age=3600、ETag和Last-Modified。浏览器在3600秒内不发出任何请求，直接使用缓存；3600秒一到，它不会直接丢弃本地副本，而是带着If-None-Match和If-Modified-Since回服务器问一句“我手里的版本还新鲜吗”。服务器返回304，浏览器更新一下缓存有效期，继续使用本地副本。

这里有个容易忽略的细节：304响应本身也可以带新的Cache-Control头，用来刷新浏览器端这条资源的缓存时长。有些团队为了“省事”，在资源过期后让策略直接变成重新下载，让用户多等一次全量传输，这是很亏的。正确做法是让协商缓存兜底，大多数情况下资源内容根本没变，一个304请求就能续命。

我再做个生活化类比：强制缓存是冰箱，协商缓存是“打电话问超市”。冰箱里的菜过期了，但你不确定超市是不是进了新货，打电话问一下，老板说“还是你上次买的那个”，你就安心继续吃冰箱里的。这一个电话（304请求）比再跑一趟超市（重新下载资源）成本低太多了。

3. 实操配置：Nginx、后端与前端的三方协同

3.1 服务端配置：给静态资源设置合理的缓存头

理解了原理，接下来就是动手配置。我以最常见的Nginx为例，一套经过大量项目验证的静态资源缓存配置长这样：

server { listen 80; server_name example.com; location /static/ { root /var/www/html; expires 30d; add_header Cache-Control "public, max-age=2592000, immutable"; } }

这个配置做了三件事：expires 30d会给响应附带一个合理的Expires头，作为旧客户端的兼容兜底；add_header Cache-Control手动指定max-age=2592000，也就是30天；immutable是给浏览器的一个强信号——这个文件永远不会变，连协商验证都不需要发。

immutable这个属性值得单独拎出来说。它的完整定义是：资源内容固定不变，重新验证没有意义。浏览器遇到Cache-Control: max-age=31536000, immutable的响应时，即使用户主动刷新页面，它也只会用本地缓存，完全跳过验证。这个特性特别适合带hash的文件名——文件内容一变，文件名就变，URL就变，根本不需要“同一个URL内容变化”的能力。

3.2 后端接口：哪些接口该缓存、哪些必须禁缓存

很多人只重视静态资源缓存，对接口数据缓存一头雾水。其实接口缓存做得好的话，能省掉大量后端计算和数据库查询压力，但一个不小心就会让用户看到脏数据。

我的实践经验分三类：

第一类：必须禁缓存的接口。包含用户登录态校验、购物车操作、支付流程、验证码获取等涉及安全和实时数据的接口。这类接口我在后端统一设置：

res.setHeader('Cache-Control', 'no-store');

no-store确保任何中间节点都不会缓存响应，用户的敏感操作每次都直达服务器。

第二类：可以用协商缓存的接口。适合那些数据可能变、但变化不频繁的接口，比如用户资料、文章列表、配置信息。后端设置：

res.setHeader('Cache-Control', 'no-cache');

同时让框架或中间件自动生成ETag。注意这里我用的是no-cache，不是no-store。加了ETag之后，浏览器每次请求都会带If-None-Match，服务器计算比对，没变就返回304空响应。这不光省了传输流量，还省了把完整数据序列化后返回的网络开销。

第三类：可以强制缓存的接口。适合几乎不变的数据，比如国家地区列表、静态字典数据、版本号信息等。设一个较长的max-age，比如24小时：

res.setHeader('Cache-Control', 'public, max-age=86400');

这里多提一句：如果项目用了CDN，还要注意区分public和private。登录用户的个性化接口即使内容不敏感，也建议用private，防止CDN把某个用户的响应缓存后发给其他用户。

3.3 前端构建：打包产物文件名hash与配合

前端开发者在缓存这件事上也有一份重要的作业：打包产出物的文件名必须带内容hash。

现在的主流构建工具都内置了这个能力。比如Webpack的contenthash配置、Vite的默认构建行为，都能把代码生成app.a1b2c3d4.js这样的文件名。这个hash是根据文件内容计算出来的，只要代码变了，hash就变，文件名就变，URL就变。之前设置的超长缓存继续生效，因为新文件名对浏览器来说是一个全新的资源，必然回源下载。

这里有一个常见误区：有些人图省事，自己给静态资源URL手动添加版本参数，比如app.js?v=20250201。短期内确实能达到“强制更新”的目的，但时间长了会有一堆问题：手动维护版本号容易漏改、改动一个文件却把全部引用的版本号都改了造成不必要的回源、和构建工具的自动hash机制冲突。构建工具自动生成的hash是可持续、低成本、零心智负担的方案，我强烈建议采用这套。

前端协作的关键点在于：HTML页面本身不要设置长缓存。因为HTML是引用这些带hash资源的入口，如果HTML被缓存了，它里面写的还是旧的文件名引用，那JS/CSS的hash更新再完美也白搭。所以HTML的响应头应该设Cache-Control: no-cache，每次访问都验证一下。

4. 缓存更新换代：用户为什么总是看到“旧页面”

4.1 传统版本号更新的痛苦

我碰到过不少项目团队，发布新版后总在群里喊“我这边看着是新的，用户那边怎么还是旧的”。这种问题的根源几乎都是缓存更新策略没设计好。早期项目常用的方案是在引用资源时加版本号，类似<script src="/js/app.js?v=20240101">。看起来简单直观，但问题不少：一个页面引用了七八个文件，每次发版把所有文件的版本号都改一遍，难免遗漏；开发同学容易忘记改动某个入口；而且CDN节点配置了缓存的话，带参数URL变化后回源又是一次全量新增。

更不要说那种“懒人方案”——直接把max-age设成一个很小的值甚至设为0，让所有资源每次都回源。这种做法彻底放弃了缓存的性能优势，页面加载速度会明显劣化，尤其在弱网环境下体验很差。治标不治本。

4.2 hash文件名的更新原理

内容hash文件名方案之所以可靠，是因为它把“缓存失效判断”变成了“URL是否变化”的简单逻辑。文件内容没有变化时，构建产物文件名保持不变，浏览器和CDN都可以放心长缓存，效率拉满；文件内容有变化时，文件名必然变化，新URL必然回源，用户拿到的必然是新版本。这个过程完全自动化，构建工具负责，不需要开发人员维护任何版本号，不会出现“改了忘了加”的情况。

实践中我还会配合一个细节：给使用hash文件名的静态资源额外加上immutable头。这个前面提过，它能告诉浏览器“这个URL指向的文件是永不变的”，用户刷新页面时直接跳过协商验证，体验更好。

4.3 页面本身HTML的缓存策略

虽然我现在说“HTML不要长缓存”，但在实际操作中，HTML的缓存策略也要区分场景。

对于传统的多页应用，每个页面HTML都是由后端渲染返回的，这些页面内容经常更新，所以用Cache-Control: no-cache让浏览器每次都回服务器验证，是正确的选择。这样每次访问页面，浏览器都会发一个轻量请求，拿到304后用本地缓存渲染，既保证内容新，又不会浪费太多网络开销。

对于单页应用（SPA），情况有一点不同。一个常见的做法是index.html设置Cache-Control: no-cache，然后让配套的静态资源长缓存。但注意，很多SPA部署在对象存储或CDN上时，HTML文件本身是静态文件，没法做动态协商。这时要在部署层面做成“HTML不缓存或极短缓存”，配合构建文件的hash，就能做到既安全又高效。

如果HTML被CDN缓存了并且缓存时间设置得很长，那么即使你更新了服务器上的HTML，用户访问CDN节点拿到的还是旧HTML，旧HTML引用的还是旧hash文件名。这个问题排查起来极具迷惑性，很多人以为代码没发布成功，实际上就是HTML被CDN缓存劫持了。后面我单独讲排查方法。

5. 踩坑记录与排查技巧

5.1 改完代码不生效，紧张兮兮以为部署失败了

这是一个新手和老手都会遇到的问题：发版之后用浏览器打开，发现还是老页面。第一反应是“是不是部署出问题了”，然后各种查日志、查服务器、重启服务，折腾半天才发现只是本地缓存作怪。

我的排查顺序很固定：先看是不是缓存问题，再看是不是部署问题。怎么判断？先打开无痕窗口访问页面，如果无痕窗口能看到新内容，那基本确定是原窗口缓存问题。或者直接强刷页面：Windows下按Ctrl + Shift + R，Mac下按Cmd + Shift + R。强刷的本质是浏览器在请求头里自动加上了Cache-Control: no-cache，迫使所有资源都回源验证，这样一般能拿到最新内容。强刷能看到新页面，就说明代码确实部署成功，只是常规模式下浏览器用了缓存。

注意一个例外：如果你给静态资源设置了immutable，并且用户刷新的是已经缓存的hash资源，部分浏览器即使是普通刷新也会跳过验证直接走缓存。这种时候强刷也不一定能绕过immutable的缓存策略，最干净的验证手段还是无痕窗口。

5.2 缓存命中情况怎么用DevTools和抓包工具看

很多前端同学天天用浏览器开发者工具，但没仔细看过Network面板里的缓存命中信息。这里值得花点时间讲清楚：

看一个请求的Size列，如果显示(memory cache)，表示命中了内存缓存，资源直接从浏览器内存读取，没有网络请求；如果显示(disk cache)，表示命中了磁盘缓存，虽然也是本地读取，但数据从硬盘加载，速度比内存缓存慢一点。如果显示一个具体的文件体积，比如1.2 MB，说明这次请求回源下载了完整资源。如果显示304，说明走了协商缓存，服务器确认资源没变，没有下载正文。

用抓包工具（比如Fiddler或Charles）能看得更细：可以看到请求返回的响应头里到底带的是Cache-Control的什么值、有没有ETag、Last-Modified的时间等等。抓包工具尤其适合排查“为什么没走缓存”这类问题——有时是服务端Gzip或代理改了响应头，有时是请求路径带了随机的query参数导致URL变了。

5.3 过期的长短之痛：max-age到底该设多大

配置max-age时最纠结的是“设大怕不更新，设小怕没效果”。我的经验值如下，供参考：

图片资源设30天而不是一年，是因为项目里有时会替换LOGO或活动图，图片不带hash，更新时希望在一定时间内生效。如果图片更新频繁，可以换成带版本号的目录结构或hash命名。

5.4 CDN缓存与源站缓存不一致的排查

如果你用了CDN，问题的复杂度会再上一个台阶。CDN在源站前面，浏览器请求会先打到CDN节点，CDN节点按自己的缓存规则处理。即使源站的响应头写得再正确，CDN也可能因为缓存配置不同而缓存了旧内容。

做项目时我的原则是“CDN配置跟源站保持一致，并以CDN侧配置为优先”。比如在CDN控制台把某个目录的过期时间设为0（不缓存）或短期缓存，而源站仍然设置长缓存，这样CDN的覆盖规则会优先生效。还有一种情况：源站返回了Cache-Control: private，但CDN不认，照样缓存，把某个用户的响应内容发给所有用户，那就麻烦了。因此配置CDN之前一定确认一下它的缓存策略是按“源站响应头”还是按“CDN自定义规则”执行的。

另外排查CDN缓存问题有一个笨但有效的方法：在URL后面临时加上一个query参数（比如?test=1），如果加参数能拿到新内容，去掉参数还是旧的，那基本可以断定CDN节点缓存了旧版本。这种情况在CDN控制台刷新缓存，一般能解决。

6. 结尾补充：一个反复验证过的组合策略

最后分享一套我反复使用的组合策略，算是这几年踩坑之后沉淀出来的“模板”。前端构建用工具生成hash文件名；Nginx或CDN对带hash的静态资源返回public, max-age=31536000, immutable；对HTML页面返回public, no-cache；对登录态和交易接口返回no-store；对稳定字典接口返回public, max-age=86400并配合ETag。这套方案兼容了性能、实时性和安全性，我用到目前还没有遇到绕不开的坑。

还有一个容易被忽略的细节：服务端返回Cache-Control头时，如果既要兼容老浏览器又要支持新特性，可以把Expires和Cache-Control同时带上，让老浏览器用Expires，新浏览器认Cache-Control。这也是很多成熟框架默认做的事情。

大家如果对照这个思路去检查自己的项目，把响应头逐个过一遍，很多“页面更新看不到”“接口老数据”的问题当场就能定位出来。缓存这件事本身不难，难的是把每一条规则的边界想清楚。希望这篇基于http缓存的实践总结能帮你在处理缓存时少走一些弯路。