「动态内容不能上 CDN」这句话，已经过时了
这个说法来自十几年前的 CDN 架构。那时候节点上跑的就是一台缓存服务器，规则很简单：命中缓存就吐，没命中就回源。动态页面每次内容都不一样，命中率接近零，请求还得绕到边缘再回源，等于白多一跳。当年的结论没问题。
但现在 CDN 边缘干的活早就不只是缓存了。TLS 终结、HTTP/2 或 HTTP/3 复用、路由选优、连接池保持、协议转换（边缘用 HTTP/3 接用户、回源走 HTTP/1.1）、基础 WAF 和限速，这些都不依赖「内容是不是静态」。用户到边缘那一段 RTT，永远比用户直连源站短，跨运营商、跨境访问时差距更明显。
准确的说法是：动态内容不适合缓存，但很适合走加速链路。行业里把「静态走缓存、动态走转发」这套模式叫全站加速，有的厂商叫动态加速或 DCDN，名字不同，底层做的事差不多。
全站加速落地，实际在做三件事
动静分离：先分清楚谁是动态
动静分离不用改业务代码，是在 CDN 配置里写规则。常见的判断维度有这么几种：
- 按后缀：.html/.css/.js/.jpg 走缓存，.php/.jsp/.do 走转发。简单粗暴，但现代应用 URL 里经常没有后缀，不适用。
- 按路径前缀：/api/、/cart/、/user/ 走动态转发，/static/、/assets/ 走缓存。目前比较通用的做法。
- 按请求方法：GET 可以尝试短缓存，POST/PUT/DELETE 一律直接转发，不进缓存逻辑。
- 按响应头：源站返回 Cache-Control: no-store 的，边缘阶段直接跳过缓存判断。
实操里建议把内容分三层看：真静态（图片、构建产物）、准静态（商品详情、文章页，能接受 10 秒到几分钟的旧数据）、纯动态（登录、下单、支付）。中间那层准静态的收益常被低估——给它加 30 秒边缘缓存，源站压力能掉一大截，用户基本感觉不到「旧」。有些团队还会用微缓存，1 到 5 秒的 TTL 专门扛秒杀或热点事件带来的突发流量。
动态路由回源：让回源这一段也别乱走
用户到边缘省了，如果边缘回源还是走公网随机路径，整体收益会被吃掉一大半。动态路由做的事是：边缘节点之间用自建骨干或专线互联，回源流量先走到离源站近的节点再进源站，同时持续探测各条路径的延迟和丢包，实时切换。
跨境场景下这段差距很大。国内用户访问美国源站，走公网可能 200ms 起步还带抖动；回源链路做过优化之后能压到 150ms 上下，反过来也一样。做跨境的团队如果只给静态资源做缓存、放着 API 裸奔，用户会吐槽「页面出来了但按钮点半天没反应」，问题就出在这。具体配置思路可以参考 跨境电商 CDN 方案。
连接复用：省的是握手，不是带宽
一个 HTTPS 请求，边缘回源要经历 TCP 三次握手加 TLS 握手，跨地域的话光这一套就 2 到 3 个 RTT。如果每个动态请求都新建连接，源站还没开始处理业务逻辑，几十毫秒已经没了。
做法是边缘到源站保持长连接池，配合连接预热，提前把连接建好；回源侧开 HTTP/2 多路复用；源站的 keepalive 超时别设太短，60 到 75 秒比较合适，否则连接刚建好就被关掉，复用等于白做。这一项单看收益不大，但它和动态路由是叠加关系，配好之后 API 的 P95 延迟通常能下去 20% 到 40%，具体看链路质量，以实际压测为准。
几个容易踩的坑
- 把 POST 也配了缓存。见过一次配置事故，运维给 /api/ 加了 10 秒缓存，结果用户提交订单后刷新看到旧状态，排查了半天。动态路径宁可不缓存，也别乱缓存。
- 鉴权信息没透传。Cookie、Authorization 头要原样转发，部分场景还得把真实客户端 IP 通过 X-Forwarded-For 传给源站，否则风控和限流统计全部失真。
- 会话没做统一。源站是多台机器又没共享 session，边缘回源还走轮询，用户就会一会儿登录一会儿掉线。回源策略要么做一致性哈希，要么先把 session 外置到 Redis。
- 健康检查太粗。只探 TCP 端口通不通，不看业务返回码，源站返回 502 了还在往那台机器打流量。建议换成 HTTP 探针加响应码判断。
- 以为开了全站加速就不用管源站带宽。回源流量该占的带宽一点没少，只是路径更顺。源站出口带宽、并发连接数该扩还得扩。
哪些场景值得上，哪些不值得
下面这张表是按我们接触过的业务形态归纳的，不是通用结论，具体还得看你的用户分布和接口耗时。
| 场景 | 是否值得 | 说明 |
|---|---|---|
| 跨境电商独立站（商品页 + 购物车 + 支付 API） | 值得 | 用户跨洲、动态请求占比高，回源链路优化的收益比较直观 |
| 国内 SaaS 后台，用户集中在一两个省 | 收益有限 | RTT 本来就短，静态资源走普通 CDN 就够，动态部分可先放着 |
| 游戏登录、支付回调、排行榜接口 | 值得 | 对延迟敏感，通常还要配合 DDoS 防护一起规划 |
| 大文件下载、视频点播 | 不算全站加速的活 | 属于静态分发，普通缓存型 CDN 更合适、更便宜 |
| 纯官网、博客 | 不需要 | 全静态内容，缓存策略配好即可 |
| WebSocket / SSE 长连接 | 看情况 | 边缘转发有收益，但要确认节点数量、空闲超时和重连策略 |
| AI 推理 API | 看情况 | 首 token 延迟主要取决于排队和算力，边缘只能省网络段那部分 |
| 源站单次响应超过 500ms | 先别上 | 瓶颈在源站处理逻辑，加速链路不解决根本问题 |
全站加速不是万能的：源站慢，谁也救不了
这句话得说在明面上。全站加速优化的是「用户到源站之间那段路」，它压不掉源站自己的处理时间。一个接口在服务器上要跑 800ms 才返回，你上多少层加速，用户那边感知还是 800ms 起步，边缘能帮你省的那几十毫秒 RTT 在这里基本可以忽略。
判断方法其实很直接：先测源站自身响应时间。用 curl 直接打源站，或者看应用层 APM 的耗时分布。如果时间大头花在源站内部，先去处理慢查询、串行调用、N+1 查询、缺索引的 SQL，再考虑加速。反过来，源站处理只要 50ms，用户端却要 400ms，那多出来的基本都是网络开销，这时候上全站加速才有意义。
另一个前提是源站得稳。边缘靠健康检查和故障摘除来保证可用性，前提是源站能稳定响应；源站本身在抖，边缘只会把抖动如实放大成更多超时。如果源站同时还扛着攻击流量，那就不是加速的事了，先看 DDoS 防护方案怎么选，把入口清干净再谈提速。
下一步怎么判断你要不要上
拉三天真实访问日志，分三列统计：静态资源请求占比、API 动态请求占比、动态请求的 P95 响应时间。静态占比高、动态 P95 里网络耗时占大头、用户地域分散——三条中了两条，全站加速基本值得试。如果用户都集中在一个城市、接口本身又慢，那笔预算花在优化源站上更划算。
真动手的时候，先切一小部分流量灰度，对比边缘和直连的 P95，看回源错误率有没有变化，别一次性全量切。想省事也可以先拿 全球 CDN 加速 处理静态部分，跑一段时间再决定要不要把动态 API 也接进来；两种模式在成本和效果上的差别，可以对照 CDN 加速与直连对比 里的维度自己算一遍。我们遇到过的客户里，从「只加速图片」一步步走到「全站加速加重防回源」的不少，中间踩的坑基本就是上面列的那些。有具体架构想让人看一眼，把业务形态、用户分布和接口耗时发到 bd@319keji.com，我们给个不带水分的判断。