网站缓存命中率上不去，多半不是服务器的事

缓存命中率这个数字，从来不是考服务器跑得快不快。你去看监控，CPU 闲着、内存富余、磁盘 IO 也没冒头，就命中率趴在低位不动。网站缓存命中率上不去多半不是服务器事，这句话我先摆在最前面，后面再慢慢讲为什么。命中率是缓存自己算出来的一个比值：分子是被缓存直接挡回去的请求，分母是所有请求。机器再强，只要该进缓存的东西没进去，或者进去了却因为条件对不上被判成 miss，这个比值照样难看。

命中率这个数是怎么算出来的

简单说，一个请求进来，缓存系统拿它的特征拼出一把钥匙，去自己的仓库里翻有没有对应的东西。找到并且没过期，算 hit；没找到、找到了但过期了、或者被响应头明确禁止使用，算 miss，得回源站要一份。麻烦的地方在于这条链上通常不止一层缓存：浏览器自己有一层，CDN 边缘节点有一层，反向代理（Nginx 的 fastcgi_cache、Varnish 这类）有一层，应用里往往还有一层对象缓存。任何一层掉链子，你在某个后台看到的那个总命中率都会被拉下去。所以看到数字低，先别急着往机器上定位。

网站缓存命中率上不去多半不是服务器事，先查这四个地方

我把踩过的坑归了归类，基本跑不出四块：缓存键拼进了不该拼的东西、TTL 设得太短或者被响应头否掉、动态内容混进了公共缓存池、后台被反复手动清缓存。这四件事全在配置层和应用层，跟 CPU 型号、跟带宽大小、跟机房落在哪个城市，关系都不大。你把服务器从这台换到那台，该 miss 的还是 miss。

缓存键里混进了不该混的东西

最常见的一种。缓存键一般由 URL、主机名和部分查询参数组成，CDN 默认往往把 query string 整个纳进去。你的模板如果给静态资源挂了个时间戳参数用来强制刷新，那每个页面引用的 CSS、JS 键都不一样，等于每次访问都是全新的，命中率能高才怪。还有链接里残留的 utm_source、会话 ID、随机数，全都被算进去了。再往深一层是 Vary 头，Vary: User-Agent 一开，同一条 URL 会按浏览器版本拆成几十上百份缓存副本，每一份的访问频次都低，命中率自然稀。我的做法是能删的参数坚决不留，必须保留的白名单化，Vary 尽量只留 Accept-Encoding。

TTL 太短，等于天天在回源

Cache-Control 里的 max-age 设成几十秒，或者干脆用 no-cache、no-store，这几种写法的含义不一样，但结果都是缓存基本不起作用。no-cache 不是不缓存，是每次都要回源校验一下；no-store 才是真的不存。这两个混用的人特别多。另外，响应里带了 Set-Cookie，不少 CDN 默认就不敢缓存这条响应，怕把别人的登录态发出去——这个判断本身没错，但如果你在静态资源上也无脑带上了 Cookie，那命中率就是自己摁下去的。还有个习惯动作：后台一有新内容就点全站刷新，缓存刚热起来又被清空，等于白建。

动态内容别硬塞进缓存池

登录后的个人中心、购物车、订单详情这类页面，不该进公共缓存。得区分处理：静态资源和匿名页面正常缓存，带登录态的一律绕过，或者按 Cookie 白名单把非必要的会话字段剔掉再做判断。这里有个优先级要摆清楚——把私有内容缓存成公共内容，那是安全事故，比命中率低难收拾得多。宁可某个目录整体不缓存，也不要去赌参数拼得刚好不冲突。

换服务器为什么解决不了

说实话，换机器唯一能改善的是回源那一段的耗时和并发能力。回源少了、源站压力小了，这是配好缓存之后的结果，不是靠堆配置堆出来的。反过来，miss 一大堆的时候，回源请求会把源站带宽和连接数吃满，页面变慢，你就以为是机器不够用，于是加钱升级，升完发现还是老样子。预算花在这儿，回报很有限。

照着这几步看一遍

先用 curl -I 连续请求同一个 URL 两次，看响应头里 X-Cache、X-Cache-Status 这类字段是不是从 MISS 变成 HIT；Nginx 可以在 log_format 里加上 $upstream_cache_status，直接从日志统计。然后去 CDN 后台看命中率的计算口径，有的按请求数算，有的按流量算，两者能差很远，具体口径以服务商文档为准。再抽一段访问日志，看重复 URL 的占比有多高。这几步做完，问题基本就露头了。

最后提醒一句：命中率是用来发现问题的，不是用来追高的。数字好看，却把该走实时逻辑的内容缓存住了，那才是真麻烦。先把缓存键和响应头捋顺，再看机器要不要动，顺序反了，钱就白花。