做前端和运维这些年被问得最多的问题之一就是页面打开慢加个页面CDN加速是不是就好了。说实话这句话对一半。CDN确实能把静态资源的物理距离压下去但它解决不了所有慢甚至配置不当的时候会让问题更隐蔽——页面看着是快了可一到发布就出缓存不一致一到秒杀就回源打爆源站。我见过好几个团队域名解析切过去控制台点了开启然后就再没管过直到某天大促流量上来源站带宽跑满才发现缓存命中率只有六成。所以这篇我想把页面CDN加速这件事从头到尾讲透它到底加速的是链路上的哪一段缓存规则该怎么设计哪些参数是真影响命中率的接入实操的完整步骤长什么样以及出问题的时候按什么顺序排查。内容偏实战写给已经准备接入或者已经接了一半的同行看也写给需要判断这活儿值不值得做的技术负责人看。看完你至少能知道你花在 CDN 上的钱有多少是真正买到效果的。1. 页面CDN加速到底在加速哪一段1.1 一次页面打开经过的四个环节先把链路摆出来不然讨论快不快都是玄学。用户从点开链接到页面可交互大致分四段DNS 解析、建立连接TCP 加 TLS 握手、首字节等待TTFB也就是请求发出去到收到第一个字节、内容传输与渲染。这四段里CDN 主要能吃下的是第二段和第三段的一部分外加第四段里的静态资源传输。DNS 这一段CDN 一般通过调度系统给用户返回就近节点的地址解析本身耗时不多但如果调度不准用户被指到一个跨省甚至跨洲的节点后面全白搭。连接建立这一段边缘节点离用户近RTT 小握手自然快再叠加会话复用和 HTTP/2 多路复用同一页面几十个请求不用开几十条连接。TTFB 这一段最微妙如果资源命中缓存边缘直接返回那基本就是几十毫秒的事如果没命中边缘要回源取这时的 TTFB 等于边缘到用户加边缘到源站两段之和反而可能比直连源站更慢。这也就解释了一个常见困惑为什么有些人上了 CDN 感觉没变化甚至首屏更慢了。原因往往不是 CDN 不行而是命中率太低绝大部分请求都在走边缘转发只赚了个就近接入的便宜却多了一跳回源。所以做页面CDN加速第一优先级永远是让该缓存的东西真正缓存住而不是纠结节点铺了多少。1.2 页面CDN这个说法里的两种含义行业里说页面CDN加速其实混着两件事。一种是静态资源加速JS、CSS、图片、字体、视频切片这些内容特点是内容稳定、可以长时间缓存是 CDN 最经典的战场。另一种是整页 HTML 的加速包括 HTML 文档本身、服务端渲染出来的首屏结构这类内容带用户态、更新频繁处理起来难度高一个量级。两者混在一起谈最容易出的问题就是规则一刀切。我见过把 HTML 也设成一小时缓存的配置上线当天首页还是旧版用户点进详情页发现价格是昨天的。也见过相反的全站no-storeCDN 一点缓存都不做等于花钱买了个转发器。比较靠谱的做法是把资源按是否带用户态和更新频率两个维度分成三类分别给策略带指纹的静态资源app.a1b2c3.js这种、公共静态资源logo、通用库、HTML 与接口。第一类可以放心长缓存第二类给中等 TTL 加协商缓存第三类要么不缓存要么极短 TTL。分类这件事想清楚了后面 80% 的坑都不会踩。2. 整体方案设计缓存分层比节点数量更关键2.1 三层缓存与回源收敛一个成熟的 CDN 网络不是一堆平行节点而是分层的。最贴近用户的是边缘层L1只放最热的内容存储小、命中快往上一层是中间层或者叫父层L2缓存容量大得多承接边缘未命中的请求再往上才是源站。这三层设计的目的只有一个词回源收敛。打个比方边缘层像小区门口的便利店中间层像城区的大仓源站是工厂。如果每个便利店缺货都直接打电话给工厂工厂的电话线必然被打爆正常做法是便利店向大仓要货大仓没有才找工厂。CDN 里的逻辑完全一样一个热门文件在 200 个边缘节点都没命中如果不分层就是 200 次回源有了父层边缘向父层回源父层只向源站回源一次源站压力从 200 降到 1。这个机制对页面CDN加速的意义在哪在于突发流量的抗性。新版本发布、活动页上线、爆款内容扩散这些场景的共同点是同一批资源在极短时间内被大量用户请求。分层结构能在几分钟内把回源量压到源站能承受的水平而纯扁平结构在这个窗口期很可能直接把源站打挂。选服务商的时候问一句有没有分层回源、父层覆盖率多少比问你们有多少节点有用得多。2.2 缓存键的设计决定命中率上限缓存键Cache Key是 CDN 判断这个请求是不是我要的那份缓存的依据默认通常是协议 域名 路径 全部查询参数。这个默认值在真实业务里经常是灾难因为页面上大量 URL 带着业务无关的参数。举个特别典型的分享链接带?fromtimelineisappinstalled0广告投放带?utm_sourcexxxutm_campaignyyy前端埋点带?t1699999999。这些参数一变缓存键就变同一份资源在边缘被存了几十上百份副本命中率自然崩。我接手过一个站点图片命中率长期在 55% 左右晃排查半天发现是图片 URL 后面挂了防缓存的随机数一行代码改掉之后直接干到 94%。所以缓存键必须主动设计。常见的处理是设忽略参数把utm_*、from、spm、t、timestamp一类加进忽略列表更严格的做法是参数白名单只有明确参与内容生成的参数比如id、page、lang才进缓存键其余全部忽略。白名单更安全代价是每上一个新功能要评估参数但换来的是可预期的命中率。除了查询参数缓存键还有几个可选维度用不用要看业务维度什么时候需要代价设备类型PC/移动/平板服务端按 UA 输出不同 HTML缓存副本翻倍需边缘识别而非Vary: User-Agent语言/地区多语言站点按 IP 或参数分流副本数乘以语言数编码格式gzip/Brotli基本都需要通常由 CDN 自动处理无额外配置成本Cookie 分组登录态与游客内容差异大分组过多会击穿命中率慎用注意不要用Vary: User-Agent来做设备适配。UA 字符串几乎是无限长的组合缓存键会碎成渣命中率接近零。正确做法是在边缘用规则判断出设备类型再把这个类型作为缓存键的一个受控维度。2.3 静态与动态资源要分开谈静态资源加速的思路很直接给文件加内容指纹长缓存发布即换 URL。真正需要花心思的是动态部分尤其是 HTML。这里有个认知必须先立起来HTML 本身要不要缓存是个业务问题不是技术问题。如果 HTML 完全个性化比如首页推荐位千人千面那就不该在 CDN 缓存或者只能对游客态做短缓存。如果 HTML 是通用的内容页、活动页、文档页那完全可以缓存几十秒到几分钟用短 TTL 快速刷新来平衡时效与性能。中间还有一类是骨架通用、局部个性化这种最考验设计主流做法是 HTML 缓存个性化区块用客户端异步请求填充或者在边缘做片段组装。把这三类分清楚规则表才好写。我给一个我常用的分类模板实际项目里按它填一遍基本不会有遗漏内容页 HTML短缓存 发布刷新、带指纹的 JS/CSS一年 immutable、未带指纹的公共库一天 协商、图片按是否可覆盖更新决定可覆盖的一小时带指纹的一年、字体一年、接口 JSON默认不缓存少数只读列表接口给 5 到 30 秒。3. 缓存策略的核心参数与配置细节3.1 强缓存与协商缓存的组合拳浏览器和 CDN 判断缓存靠的是响应头。真正起作用的就那么几个但组合方式决定了行为差异。强缓存由Cache-Control: max-ageN控制在有效期内浏览器根本不会发请求直接从本地磁盘或内存取。这是最省时间的方式0 网络开销。协商缓存靠ETag或Last-Modified浏览器会带着If-None-Match或If-Modified-Since去问服务端返回 304 就复用本地副本。它省的是传输体积不省往返时间。两种方式的选择标准很简单内容变了 URL 会不会变会变用强缓存加长 max-age不会变用协商缓存或者短 max-age 加协商兜底。所谓内容指纹就是让 URL 跟着内容变——文件名里塞一段内容哈希内容一改文件名就改旧文件永远不被覆盖。这种情况下max-age31536000, immutable是完全安全的immutable还能告诉浏览器别再发协商请求了我保证不变。Cache-Control: public, max-age31536000, immutable反过来如果资源是logo.png这种固定文件名、会被覆盖更新的就绝对不能给一年缓存否则用户一年内都看不到新图。这种要给短 TTL 加协商Cache-Control: public, max-age3600, must-revalidate ETag: a1b2c3d4还有一个特别实用的组合是stale-while-revalidate和stale-if-error。前者意思是过期之后先拿旧的给用户同时后台去回源更新后者是回源失败了也别报错先给旧内容顶着。这两个指令对可用性的提升非常明显——源站抖一下、回源超时几秒用户完全无感只是短暂看到稍旧的内容。对新闻、商品详情这类旧一点没关系的页面我基本都会加上Cache-Control: public, max-age60, stale-while-revalidate30, stale-if-error6003.2 TTL 到底设多久按资源指纹倒推TTL 拍脑袋定是常见毛病。有人一律 3600有人一律 300都没什么依据。合理的做法是倒推这个资源更新后业务能容忍多久的延迟假设一个内容页运营改完标题希望一分钟内全网生效。那 TTL 就不能超过 60 秒同时要配发布时的主动刷新。如果运营能接受十分钟TTL 给 300 到 600 秒都行配合刷新兜底。而带指纹的 JS业务容忍度是新版本发布后用户刷新一次就能拿到新的——因为文件名变了URL 是新的根本不存在旧的被缓存的问题所以可以给一年。这里有个容易被忽略的点CDN 的 TTL 和浏览器的 max-age 不必相同。实践中经常是边缘缓存时间长比如 1 小时浏览器缓存时间短比如 5 分钟。这样边缘命中率高、回源少同时用户端又能较快感知更新。有些 CDN 支持通过单独的响应头指定边缘 TTL比如CDN-Cache-Control一类具体字段名各家不同配置时看文档。还有一个经验值对于内容会被覆盖更新的资源TTL 别设太长因为一旦设长了出问题时你只能靠刷新来救而刷新是有配额、有生效延迟的。我一般给这类资源 1 到 6 小时既保证命中率又不至于在事故时束手无策。3.3 容易被忽略的 Vary、Cookie 与查询参数Vary这个头在 CDN 场景下杀伤力被严重低估。它的语义是这个响应随哪个请求头变化。Vary: Accept-Encoding是合理的因为压缩变体确实不同Vary: User-Agent是灾难Vary: Cookie更是灾难中的灾难——几乎每个请求的 Cookie 都不一样等于每份响应都是独一份缓存彻底失效。比Vary更隐蔽的是Set-Cookie。很多 CDN 的默认行为是响应里带Set-Cookie就不缓存这本来是防止把用户 A 的会话发给用户 B 的保护机制但如果源站无脑给所有响应都种 Cookie比如某些框架默认给每个请求下发 session id就会导致静态资源也全都不缓存。这种情况的典型症状是规则怎么调命中率都上不去抓包一看每个响应都有Set-Cookie。解决思路是分两类处理。对纯静态资源直接在边缘把Set-Cookie剥掉再缓存对 HTML 和接口要么治理源站只在该种 Cookie 的时候种要么把带用户态的请求分流到不缓存的规则上。我个人的偏好是后者宁可少缓存一点也不要冒串号的风险——把登录用户的页面缓存成游客版本发出去或者更糟把 A 用户的页面发给 B这类事故的代价远大于那点带宽钱。还有Range请求。视频、大文件用分片下载时边缘如果对每个 Range 请求都单独回源整文件回源量会爆炸。现在主流 CDN 都支持分片回源即边缘发现未命中时按 Range 分片拉取多个节点还能并行拉同一文件的不同片段拉完拼起来存。这块属于服务商能力接入前确认一下有没有对多媒体内容多的站点差别很大。4. 实操一次完整的页面CDN接入过程4.1 域名、证书与回源配置接入第一步是域名规划。加速域名不能和源站主域名相同会循环常用做法是static.example.com给静态资源、img.example.com给图片、www.example.com走全站加速。子域划分的意义不只是管理方便更重要的是可以按域名配不同的缓存策略和证书规则清晰出问题影响面可控。第二步是证书。整站 HTTPS 之后证书管理成了运维的日常。要注意三点一是证书要覆盖所有加速域名包括可能被遗忘的二级子域二是回源时如果走 HTTPS边缘到源站也要校验证书很多回源 502就是源站证书过期或者证书链不全导致的三是证书到期要有监控别指望服务商的提醒邮件自己配个提前 30 天的告警。第三步是回源配置这块坑最多。核心是三个值回源地址源站 IP 或域名、回源 Host发什么 Host 头给源站、回源协议HTTP 还是 HTTPS。最常见的错误是回源 Host 和源站期望的不一致。比如源站是虚拟主机靠 Host 头区分站点CDN 默认回源 Host 是加速域名源站收到static.example.com这个 Host 直接返回 404。解决办法是显式配置回源 Host 为源站真实域名。还有一个细节回源端口、超时时间和重试次数。超时时间设太短源站稍微慢一点就判失败误判率高设太长边缘的并发连接被占满反而拖累其他请求。我通常设连接超时 3 到 5 秒、读超时 15 到 30 秒重试 1 到 2 次且只对 5xx 和超时重试4xx 不重试。重试次数一定要控制源站已经扛不住的时候每次失败都重试两次等于把压力放大三倍很容易形成重试风暴把源站彻底打死。4.2 缓存规则表与配置片段规则配置是接入的核心工作我的习惯是先画一张表把资源类型、匹配规则、边缘 TTL、浏览器 TTL、是否忽略参数全部列清楚评审通过再往控制台里填。表大概长这样资源类型匹配规则示例边缘 TTL浏览器 max-age忽略参数带指纹 JS/CSS路径含-.[0-9a-f]{8,}.30 天1 年 immutable全部忽略公共库/libs/前缀7 天1 天全部忽略图片可覆盖img.域名下的 jpg/png/webp6 小时1 小时忽略 utm 类字体.woff2后缀30 天1 年全部忽略内容页 HTMLwww.域名的 text/html60 秒0协商白名单保留id、lang只读列表接口/api/list前缀10 秒0白名单保留page、type用户态接口/api/user/前缀不缓存不缓存不适用配置片段以常见的反向代理思路写逻辑通用字段名按各家控制台对应调整# 静态资源带指纹长缓存 location ~* \.[0-9a-f]{8,}\.(js|css|woff2)$ { add_header Cache-Control public, max-age31536000, immutable; add_header CDN-Cache-Control public, max-age2592000; } # 内容页 HTML短缓存 后台更新 回源容错 location ~* ^/article/ { add_header Cache-Control public, max-age0, must-revalidate; add_header CDN-Cache-Control public, max-age60, stale-while-revalidate30, stale-if-error600; proxy_hide_header Set-Cookie; } # 用户态接口禁止缓存 location ~* ^/api/(user|cart|order)/ { add_header Cache-Control private, no-store; proxy_pass http://origin_backend; }配置完之后一定要先验证再全量。验证方法是抓响应头看实际生效的字段而不是看控制台里填的值——中间可能被源站的响应头覆盖也可能被更靠前的规则命中。用命令行工具直接看curl -sI https://static.example.com/app.a1b2c3d4.js | grep -iE cache-control|age|x-cache|via重点看两个Age表示这份响应在边缘已经存了多久刷新几次如果Age在递增说明命中了X-Cache一类的头会直接告诉你 HIT 还是 MISS字段名各家不同。这套验证我每次都做便宜且直观。4.3 预热、刷新与发布流程改造预热就是主动把还没人访问的资源推送到边缘避免第一个用户当小白鼠。为什么需要因为冷启动时一个页面的几十个资源会同时回源如果正好赶上发布后所有用户都在刷新源头会瞬间被打出尖峰。预热把这次尖峰提前消化掉。预热要有优先级不是什么都推。我的顺序是HTML如果缓存→ 首屏 CSS → 首屏 JS → 字体 → 首屏图片。一页推 10 到 20 个关键资源足够推全站不仅配额扛不住长尾资源的收益也很低。预热还有一个讲究是推新 URL因为带指纹的版本一上线 URL 就变了边缘自然没有缓存这时候预热才有意义。刷新是反过来的操作用于内容被覆盖更新后强制失效。三种方式各有用处URL 刷新最精准最快适合少量文件目录刷新范围大但生效慢适合整批更新标签刷新最优雅发布时给资源打上业务标签比如product-12345需要失效时按标签刷一次能刷掉一个商品相关的所有资源特别适合商品详情、文章这类一条数据对应多个资源的场景。发布流程要跟着改。以前发布就是传文件、重启现在要加两步先预热、再切流量。完整顺序我一般这么走构建产物上传到源站此时新 URL 已可访问→ 预热关键资源 → 灰度切 1% 到 5% 流量观察错误率和命中率 → 全量。回滚的时候反过来切回旧版本入口 → 按标签或目录刷新 → 预热旧版本关键资源。这套流程看着啰嗦但真出过事故的人都知道多花五分钟比线上被用户骂一晚上划算。4.4 容量与带宽估算含计算过程做方案要给数字不然说服不了人。这里演算一遍最常见的估算你可以直接套。假设站点日均 PV 500 万单页平均触发资源请求 60 次JS、CSS、图片、字体、接口加起来则日总请求数为 500 万 × 60 3 亿次。资源平均大小按压缩后 100KB 估这个值随站点差异大图文站高、工具站低日总流量 3 亿 × 100KB 30TB。平均带宽 30TB ÷ 86400 秒 ≈ 347MB/s ≈ 2.8Gbps。峰值按平均的 3 倍算边缘侧峰值带宽约 8.3Gbps。再看回源。命中率 90% 时回源请求 3000 万次回源流量 3TB/天折算平均约 34.7MB/s也就是 278Mbps 左右峰值接近 850Mbps。如果把命中率提到 97%回源请求降到 900 万次回源流量 0.9TB/天平均约 10.4MB/s约 83Mbps峰值 250Mbps 上下。这组数字说明什么命中率从 90% 提到 97%源站带宽需求降到原来的三分之一。这就是为什么我一直强调命中率优先于节点数量——它是乘法关系不是加法关系。缓存容量也要估。边缘节点不是无限盘它靠淘汰策略维持热点。粗算热门资源集合假设 20 万个文件平均 50KB总大小 10GB给每个节点配 200 到 500GB 缓存盘足以覆盖热点集合并且留足冗余。如果你的站点有大量大文件视频、安装包那要单独评估别和图片混在一个容量模型里算。5. 动态内容与接口的加速思路5.1 链路优化的实质动态内容没法缓存那 CDN 还能做什么答案是优化最后一公里之外的传输路径。用户到源站之间可能跨越多个网络、多次互联互通中间任何一段拥塞或丢包都会体现在 TCP 重传和握手等待上用户感受到的就是转圈。CDN 在这个环节的价值是把用户到源站的一条长链路拆成用户到边缘的短链路加边缘到源站的长链路后一段由服务商自己维护通常走更优的路径、更稳的互联、更积极的拥塞控制策略。效果在弱网和跨地域场景下最明显——同样是 200 毫秒 RTT 的内陆城市用户走优化链路的首字节时间可能只有直连的一半。不过要提醒一句动态加速不是万能的。如果源站本身处理一个请求要 800 毫秒慢查询、串行调用链路再怎么优化也只能省掉几十毫秒。所以上线动态加速前先看源站的 TTFB 构成把自身耗时降下来加速才有意义。顺序反了钱花了效果不明显。5.2 个性化页面能不能缓存这是个高频问题。我的回答是能但要拆。做法叫页面分片或者边缘组装——把页面拆成公共骨架和个性化区块骨架部分正常缓存个性化区块用三种方式之一处理客户端异步拉取最简单代价是多一次请求、边缘侧发起子请求组装性能好配置复杂、源站用 ESI 一类的标签声明片段依赖源站改造。还有一种轻量做法是游客态缓存 登录态回源。边缘检查请求有没有登录 Cookie没有就返回缓存的游客版本有就放过到源站。这对内容型站点效果极好因为大部分流量是未登录用户缓存能覆盖七八成。风险点在于游客版本里绝对不能混进任何用户数据配置时要确保Set-Cookie被剥离、个性化位是占位符。我见过一个反例某站点为了提命中率把带用户昵称的页面也缓存了结果 A 用户看到了 B 用户的名字。这类问题排查起来极其痛苦因为复现依赖缓存状态。所以涉及用户态的缓存宁可保守。6. 效果验证与监控指标6.1 该盯哪几个数CDN 接完不是结束是开始。要盯的指标不多但每个都得看对口径。缓存命中率是第一指标但注意它有请求数口径和流量数口径两种。请求数口径反映有多少次请求被边缘接住流量口径反映有多少字节没回源。两者可能差很远——命中率 95%请求数但流量口径只有 70%说明未命中的都是大文件。两个都要看别只看一个。回源率和回源 QPS直接关联源站压力是容量规划的输入。边缘首字节时间和整体下载耗时反映用户体验要分地区、分运营商、分协议版本看。5xx 率和4xx 率反映健康度5xx 上涨通常意味着回源出问题4xx 上涨可能是规则误配或者资源路径变了。还有一个我必看的各协议的请求占比。HTTP/2 和 HTTP/3 的占比如果很低说明要么证书配置有问题要么部分中间设备在降级这时优化连接复用的收益还没吃到值得查。6.2 命中率突然下跌的排查顺序命中率掉了是最常见的告警按这个顺序查能覆盖九成情况看是不是发布引起的。新版本是不是给资源加了时间戳参数、是不是改了文件名规则从带指纹改成不带、是不是把原本分域的静态资源合到了主域。看源站响应头变了没。是不是新增了Set-Cookie、Cache-Control从 public 变成了 private、Vary多了维度。这类变化经常是框架升级或者中间件配置改动带来的改动的人根本不知道会影响缓存。看 URL 结构变了没。新增了筛选参数、分页参数、排序参数长尾 URL 暴增每个都是一份新缓存命中率必掉。这种情况要么做参数白名单要么对这些页面不缓存。看是不是刷新太频繁。有人为了保证实时配了定时批量刷新等于每隔几分钟就把缓存清一遍命中率永远上不去。看流量结构变了没。突然来了大量爬虫或者新渠道流量访问的都是冷门 URL命中率自然低。这种情况要看绝对值别被比例骗了。7. 常见问题与避坑清单7.1 高频故障速查表下面这些是我这些年遇到频率最高的按症状整理成表方便对照症状大概率原因处理方式回源 404直连源站正常回源 Host 与源站虚拟主机不匹配显式指定回源 Host 为源站域名回源 502/526源站证书过期、证书链不全、回源端口不通补全证书链校验端口与协议静态资源命中率长期低于 70%URL 带随机参数、响应带Set-Cookie、Vary过宽配参数忽略、边缘剥离 Cookie、收窄Vary发布后用户仍看到旧页面HTML TTL 过长且未刷新缩短 TTL发布流程加目录/标签刷新页面串号看到别人的信息带用户态的页面被公共缓存该类页面设private, no-store或按 Cookie 分流首次访问极慢之后正常冷启动回源未预热发布前预热首屏关键资源大促期间源站带宽打满命中率不足、重试放大、无分层回源提前压测、限制重试次数、确认分层能力301 跳转改不回来永久重定向被长缓存重定向响应给短 TTL 或不缓存图片更新后部分用户看到旧图固定文件名 长 TTL改为带指纹文件名或缩短 TTL 加刷新7.2 几条用事故换来的经验第一条Cache-Control一定要由源站控制别在边缘硬写。边缘硬写看起来省事但会让源站的意图失效日后排查时两处配置打架谁也不知道最终生效的是哪个。正确姿势是源站输出准确的头边缘只在必要时做覆盖并且覆盖规则要写注释、进版本库。第二条所有永久的东西都要留后路。一年缓存、301 重定向、immutable这些用起来爽但一旦配错恢复周期以小时甚至天计。我的习惯是给长缓存之前先确认 URL 一定带指纹给 301 之前先想清楚这个地址未来三年会不会变immutable只用在真正不会变的资源上。第三条压缩和缓存要一起考虑。文本资源开 gzip 或 Brotli能省六七成体积但要注意不同压缩变体的ETag必须不同否则协商缓存会返回错误的副本。图片别再二次压缩改成按Accept头转 WebP 或 AVIF 更划算同时记得把格式维度纳入缓存键不然会把 WebP 发给不支持的客户端。第四条给回源加保护。回源 QPS 上限、并发上限、熔断阈值这三样配了之后源站至少不会被 CDN 拖死。我见过最惨的一次是源站数据库慢查询响应从 50 毫秒变成 5 秒边缘大量超时重试回源 QPS 翻了三倍直接把数据库压垮形成正反馈。有熔断的话边缘在检测到回源错误率超阈值时直接返回旧内容或错误页源站还有喘息机会。第五条灰度必须按地域或运营商做不要按百分比随机。随机灰度会让同一个用户的请求时而命中新节点时而命中旧节点缓存状态混乱问题难复现。按地域切一个区域内状态一致出问题影响可控、回滚干净。第六条把 CDN 配置纳入版本管理。控制台点出来的配置也是代码也应该有变更记录、有评审、有回滚方案。我知道这听起来很重但比起某天发现某条规则被人改过但没人记得这点成本太值了。我个人在实际操作中的体会是页面CDN加速这件事技术门槛不高难点全在想清楚三个字想清楚哪些内容能缓存、能缓存多久、更新后怎么让用户拿到新的。这三件事定了配置就是照着填这三件事没定配置填得再花哨也只是把问题延后到流量上涨的那天。所以每次有新同学问我怎么配 CDN我都先让他把那张资源分类表填一遍——表填明白了剩下的都是执行。