CDN系统基本配置：缓存和回源谁更该优先

缓存和回源打架，几乎每个站点接上 CDN 的头一个月都要遇上一次。默认配置跑起来看着挺顺，一出问题就往回源上加机器，加完发现没快多少；或者反过来，缓存开得猛，编辑改了稿子刷新十遍用户那边还是老内容。cdn系统基本配置这件事，难的不是把开关拨到 on，而是判断哪类请求该让边缘节点扛、哪类必须老老实实回源拿最新的。优先级排错的代价，通常是内容脏了或者源站被压穿，两种都不好收场。

cdn系统基本配置里，缓存和回源到底谁优先

我的习惯是先给请求分个类，别一上来就调参数。分法很土：内容变不变、变了以后多久必须让用户看见、看见旧的会不会出事。三个问题问完，优先级基本自己浮出来了。图片、字体、CSS、JS、视频切片这类，换了也不影响业务逻辑，缓存优先没商量；商品详情页可以缓存几分钟到几十分钟，靠刷新缓存兜底；登录态、购物车、下单、支付回调、库存扣减，这些一律回源优先，能不碰缓存就别碰。

有人喜欢反着来，先把所有东西都缓存上，出事再一个个加白名单。这活儿干起来很爽，上线当天命中率数字好看，然后某天一个用户截图过来，说他登进去看到的是别人的订单。这不是 CDN 坏了，是配置的时候没想清楚。按服务商文档的说法，多数 CDN 默认跟随源站的 Cache-Control，源站不写，节点就自己猜，猜出来的结果往往不太妙。

静态文件：缓存优先，别客气

图片、字体、打包后的 js 和 css，这些给长 TTL 就行，max-age 直接拉到一年，配合文件名带 hash 的版本化方案，改版的时候链接一变，旧缓存自然没人访问了。麻烦的是那些文件名不变、内容直接覆盖的老站点。图换了、名字没改，边缘节点还拿着上周的版本，用户清浏览器缓存也没用，因为脏的那一份在中间。这种站点我一般会先改成带版本参数的引用方式，实在改不了就在后台手动刷，但要清楚刷新有生效延迟，也有配额，别把它当日常操作。

TTL 设多长，取决于你多怕脏数据

TTL 本质是个风险参数，不是性能参数。设长了，命中率高、回源少、源站轻松，代价是内容更新慢半拍；设短了，数据新鲜，回源请求全压到源站，CDN 挂了个寂寞。中间那条线每家业务不一样，新闻资讯类的列表页能忍一两分钟，价格库存这类基本不能忍。有些服务商支持 stale-while-revalidate 这类指令，让节点先返回旧副本同时去后台拉新的，具体支持到什么程度，以官方文档说明为准，别看着一篇博客就照抄。

缓存键配错，命中率怎么都上不去

这一段是 cdn系统基本配置里最容易被跳过、又最容易出事的：缓存键。默认键一般带上完整 URL，于是 utm_source、fbclid 这类营销参数会把同一个页面裂成几百份缓存，命中率自然上不去。可以把明确不影响的参数忽略掉，但别图省事整段 query 全忽略，page=2、id=123 这种是真的影响内容。另外 Cookie 和 Vary 也要拎清楚，随手勾一个忽略 Cookie，登录页被缓存给下一个访客，那就是事故。

回源优先的那一类：登录、下单、库存

动态路径没什么可纠结的，直接给 no-store 或 private，或者在 CDN 后台按路径关掉缓存，别在源站代码里跟缓存策略打架。这类请求回源的另一个坑是回源 host 和端口，源站换了证书或者改了监听端口，节点那边还是老配置，报出来的就是一片 502，看着像源站挂了，其实是回源信息没同步。

回源不是越勤越安全

有些人为了保险，把缓存时间压到极短，觉得回源越多数据越准。结果就是源站带宽被打满，节点层反而成了个纯粹的中转站，钱花了、性能没省。真要兼顾，可以靠预热和刷新来控节奏：大促前把热点内容预热到边缘，活动结束主动刷掉，而不是把 TTL 一刀切短。回源超时和重试次数也别乱调，调得太激进，源站偶尔抖一下会被放大成雪崩。

上线后先盯这几个数

配置改完别就撒手。看命中率，按流量和按请求两个口径都看，差值大通常说明大文件命中好、小请求漏得多；看回源率，突然抬头一般是缓存键被污染或者 TTL 到期集中失效；看回源响应时间，这个数涨了多半是源站自己的问题，不是节点；再看 5xx 比例，用来判断是回源信息配错还是源站真挂。我习惯每次改完配置记一笔时间和改了什么，出问题回溯起来省事得多。

要落地其实就三步：先把请求分成静态、半静态、动态三堆，静态给长 TTL 加版本化，动态直接关缓存，半静态用短 TTL 加主动刷新兜底；然后回头看缓存键，把纯营销参数摘出去；最后上线观察一两天，数据不对再回头改，别一次把所有开关都动一遍。缓存和回源的优先级从来不是一道有标准答案的题，它跟着你的业务变，今天是这个排法，下个季度可能就得重排。