网站缓存配置三层优化实测效果：同一台服务器没配缓存时并发300就丢请求，加上页面缓存对象缓存和CDN边缘缓存三层后并发跑到5000还稳稳的CPU从100%降到30%

有个做外贸站群的朋友，6个B2B站点跑在同一台2核4G的轻量云上，平时没事，一碰行业展会那几天Google爬虫加海外客户同时涌进来，CPU直接100%，好几个站轮流打不开。他第一反应是升级配置，花三百多升到4核8G，结果下个月展会又来一次，又挂了。问题的根不在配置上——他全站动态渲染，一个访客打开首页PHP就要查3次数据库，100个访客同时来就是300次查询，瓶颈在IO，加CPU没用。

后来他把缓存配了——页面缓存、对象缓存、CDN边缘缓存三层一套，同一台2核4G机器，同样的6个站点，同样的展会流量，CPU稳定在30%以下。网站缓存配置不是在"优化性能"，是在"减少不必要的计算"。这篇文章把浏览器缓存、服务器缓存、CDN缓存、对象缓存四层拆开，讲清楚每种缓存配什么工具、参数怎么设、坑在哪里。

一、浏览器缓存：最便宜的一层，90%的站配错了

浏览器缓存的核心是HTTP响应头里的Cache-Control。它告诉浏览器：这个资源你能存多久，过期之前别再找我要。配几行Nginx配置就能生效，一分钱不花，但配错的后果是用户每次刷新页面都要重新下载所有CSS、JS和图片。

这里面最容易翻车的是no-cache和no-store搞混。no-cache不是"不缓存"，而是"缓存了但每次用之前问一下服务器这东西变了没"，配合ETag或Last-Modified可以做到"内容没变就用缓存（304 Not Modified），变了就重新下载（200）"。而no-store才是真的完全不缓存。很多新手看到no-cache这个词就以为是禁缓存，直接配成no-store，用户每访问一页都重新加载所有资源。

在Nginx里配浏览器缓存很简单：

# 静态资源长缓存（必须配合hash文件名使用）location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg|woff|woff2|ttf)$ {expires 365d;add_header Cache-Control "public, immutable";}# HTML页面短缓存 + 协商缓存location ~* \.html$ {expires 5m;add_header Cache-Control "public, must-revalidate";}

二、WordPress缓存插件：五款横评，选对不选贵

浏览器缓存管静态资源，但HTML页面本身还是要经过PHP渲染。WordPress一次页面请求背后是几十次数据库查询，TTFB该慢还是慢。缓存插件就是把PHP渲染好的HTML页面存起来，下次直接返回静态文件。

WP Rocket是开箱即用的标杆——装上去点一下"激活缓存"，80%的优化自动完成。CSS/JS合并压缩、延迟加载、预加载缓存、数据库清理全内置。代价是收费，单站$59/年，5个站就是$295/年。LiteSpeed Cache免费且性能最强，但只限LiteSpeed/OpenLiteSpeed服务器。W3 Total Cache免费、功能全，但设置项太多了，新手进去像进了飞机驾驶舱。

三、Nginx层面缓存：跳过PHP，直接干到文件系统

WordPress缓存插件说到底还是PHP层面的方案——插件运行在WordPress框架内，命中缓存时确实不用查数据库了，但PHP进程还是要启动的，WordPress核心还是要加载的。如果你的并发很高，光是PHP-FPM的进程管理就已经是瓶颈了。

Nginx自带的fastcgi_cache在Web服务器层面就拦截了请求——命中缓存时Nginx直接从磁盘返回静态文件，连PHP-FPM都不经过。请求链路从"Nginx → PHP-FPM → WordPress → MySQL"直接缩短成"Nginx → 磁盘文件"。

# 第一步：http块中定义缓存区域fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=WP:100m inactive=60m;# 第二步：server块中启用set $skip_cache 0;if ($http_cookie ~* "wordpress_logged_in") {set $skip_cache 1;}location ~ \.php$ {fastcgi_cache WP;fastcgi_cache_key "$scheme$request_method$host$request_uri";fastcgi_cache_valid 200 301 302 60m;fastcgi_cache_valid 404 1m;fastcgi_cache_use_stale error timeout updating;fastcgi_cache_bypass $skip_cache;fastcgi_no_cache $skip_cache;}

几个容易被忽略的细节：fastcgi_cache_key的设计，上面用了\$scheme\$request_method\$host\$request_uri，HTTP和HTTPS会有两份缓存。如果全站HTTPS可以把\$scheme去掉。缓存旁路必须跳过已登录用户（wordpress_logged_in cookie），否则后台编辑完前台还是旧缓存。fastcgi_cache_use_stale在PHP-FPM挂掉时返回过期缓存而不是502，非常救命。

还有一个选择是OpenResty + Lua + Redis的方案。比起fastcgi_cache存磁盘，Redis存内存的读写速度更快，天然支持按key过期和删除。但技术门槛高，需要会写Lua脚本、懂OpenResty配置。

四、Redis对象缓存：解决"同一个查询反复打MySQL"的问题

页面缓存解决了"同一个页面反复访问"，但WordPress另一个性能黑洞是数据库查询。每个页面加载都要查菜单、查侧边栏、查配置、查文章列表——这些查询结果短时间内不变，但每次都去MySQL跑一遍。对象缓存就是把数据库查询结果缓存到内存里。

对WordPress来说Redis几乎是无脑选。原因是WordPress的查询结果经常是一大串对象数据——wp_posts表的一行转成的WP_Post对象。Memcached的1MB单key限制在复杂页面场景下会翻车，而且不支持持久化意味着服务器重启一次，缓存全部重建，数据库压力骤增。

Redis配WordPress推荐用Redis Object Cache免费插件，填host和port点启用就行。但注意：启用了Redis对象缓存后修改主题或插件代码，需要手动清缓存，否则前端可能还是旧数据。

五、CDN缓存：从源站到用户的最后一公里

前面三层缓存都是在"减少源站的计算量"。但还有一个问题没解决：你的服务器在广州，用户在伦敦打开你的网站，TCP三次握手就要几百毫秒，跟服务器性能无关，是物理距离决定的。CDN就是把内容缓存到全球边缘节点，用户访问离他最近的节点。

Cloudflare免费版是绝大多数个人站长和小团队的首选——全球300+节点、DDoS防护、免费SSL证书。但免费版的默认缓存策略比较保守：只缓存CSS/JS/图片等静态文件，不缓存HTML。意味着用户访问首页时CDN节点每次都要回源。

要突破这个限制，需要在Cloudflare里配置Cache Rules（免费版支持3条规则）。核心思路是告诉Cloudflare：HTML页面也给我缓存，按URL路径设置不同的缓存时间。

规则1：静态资源长缓存URL匹配：*.css, *.js, *.png, *.jpg, *.woff2操作：Cache → Eligible for cacheEdge TTL：30天Browser TTL：1年规则2：HTML页面中缓存URL匹配：*example.com/*（不含/wp-admin/）操作：Cache → Eligible for cacheEdge TTL：2小时Browser TTL：30分钟规则3：后台不缓存URL匹配：*example.com/wp-admin/*操作：Cache → Bypass cache

如果你的网站面向国内用户，Cloudflare的中国大陆节点是收费的（需要企业版），免费版的流量不会走中国大陆节点。这种情况可以考虑又拍云或七牛云的CDN，国内节点覆盖好，但需要域名备案。

六、四层缓存怎么组合：三种配置方案，看服务器和预算选

把上面四层缓存串起来，不是每层都要上，也不是越多越好。缓存层级多了，一致性维护成本就高，更新了一篇文章要清三层缓存才能让用户看到新内容。根据服务器环境和业务场景选组合。

七、站群场景的特殊缓存策略

如果你跑的是站群——多个网站在同一台服务器上，缓存配置要多考虑几个维度。不是每个站装个插件就完事了。

首先是缓存隔离。Nginx fastcgi_cache默认是按fastcgi_cache_key来区分缓存的，如果你的多个站点用同一个key规则（比如都是\$host\$request_uri），且key里没有区分站点的维度，A站的页面可能缓存到B站的路径下。正确做法是fastcgi_cache_path给每个站分一个独立的缓存目录，或者cache_key里包含server_name。

其次是Redis的命名空间。多个WordPress站共用同一个Redis实例时，如果不做前缀隔离，A站的文章缓存key可能会覆盖B站的。Redis Object Cache插件支持设置WP_REDIS_PREFIX常量，每个站的wp-config.php里设不同的前缀：

// 站点A的wp-config.phpdefine('WP_REDIS_PREFIX', 'site_a_');// 站点B的wp-config.phpdefine('WP_REDIS_PREFIX', 'site_b_');

第三是CDN的缓存回源。站群如果共用一个CDN域名或者同一个Cloudflare账号，要注意缓存规则不要互相污染。最好每个站单独配置缓存规则，至少按域名区分。比如site-a.com的HTML缓存2小时，site-b.com因为更新频繁只缓存30分钟。

用UC建站系统做站群的话，缓存管理可以统一收口。系统的内容中台发布文章后，自动调用各站点的缓存清除接口——WordPress站点通过REST API触发插件清除页面缓存，Nginx层面用ngx_cache_purge模块清理fastcgi_cache，CDN通过Cloudflare API刷新边缘缓存。一个发布动作串联起三层缓存的更新，不用登录每个站后台手动清。多站看板还能统一监控各站的缓存命中率、页面加载时间，哪一站缓存策略出了问题一眼就能看到。

说到底，缓存配置这件事没那么玄乎。浏览器缓存配几行Nginx、WordPress装个插件、服务器上跑个Redis、DNS接个Cloudflare，四步走完大多数站的速度问题就解决了。真正难的是一致性管理——更新了内容用户能看到新版本、缓存过期了能自动重建、哪层缓存出了问题能快速定位。单站还好说，站群一多就得靠系统化工具而不是人肉维护了。