动态API适合用CDN吗？缓存和动态加速先分清

“我们的接口返回的是动态数据，应该不能用CDN吧？”

这是讨论API性能时经常出现的一句话。它听起来很合理，却把两件不同的事情混在了一起：通过CDN传输API请求，不等于一定要缓存API响应。

商品列表、公开配置、汇率快照、文章数据这类接口，可能适合短时间缓存；用户余额、订单状态、登录信息、管理后台数据通常不能进入共享缓存。但即使完全不缓存，API请求仍然可以经过CDN节点，利用HTTPS卸载、连接复用、智能路由、安全防护和边缘接入等能力改善访问链路。

所以，动态API能不能用CDN，真正的问题不是“动态内容能不能过CDN”，而是：

• 哪些响应可以被不同用户共同使用；

• 哪些响应必须每次回源；

• CDN即使不缓存，能否改善用户到源站的网络路径；

• 缓存键能不能正确区分语言、地区、参数和用户状态；

• 缓存失效后，旧数据会造成多大影响；

• 一旦规则配置错误，会不会发生用户数据泄露。

在没有回答这些问题以前，简单地选择“全部缓存”或者“全部不缓存”，都可能让结果走向另一个极端。

先分清三件事：API缓存、动态加速和边缘计算

很多CDN服务商会同时提供静态加速、动态加速、边缘函数、API防护等功能。名称看起来相近，解决的问题却不完全一样。

API可以只使用其中一种，也可以组合使用。

例如，一个电商网站可能这样配置：

• 商品分类接口：缓存120秒；

• 商品详情接口：缓存30秒，库存字段单独实时获取；

• 用户购物车：不进入共享缓存，使用动态加速；

• 登录接口：不缓存，但通过CDN做WAF、限速和机器人防护；

• 地区配置接口：由边缘函数根据国家返回不同版本；

• 下单和支付接口：每次回源，并保留完整日志与风控校验。

因此，“API接入CDN”不是一个简单的开关，而是对不同接口分别制定规则。

动态API不缓存，经过CDN还有什么用

如果每个请求最终都要回到源站，CDN是不是只多了一层？

不一定。

用户直接访问源站时，链路通常是：

用户 → 公网线路 → 源站

接入CDN后，动态请求可能变成：

用户 → 附近CDN节点 → CDN骨干或优化线路 → 源站

即使响应不被缓存，CDN仍可能在以下环节发挥作用。

就近建立连接

用户先连接距离较近的边缘节点，TLS握手在边缘完成。CDN再通过已经建立或复用的连接访问源站，可以减少每个请求都重新建立远距离连接的开销。

效果大小与用户位置、源站位置、网络质量和CDN实现有关。用户和源站本来就在同一个城市时，增加一层CDN未必更快；跨国家、跨运营商或者链路不稳定时，改善可能更明显。

连接复用

API通常不是只请求一次。一个页面或App可能连续调用用户信息、商品列表、推荐、通知等多个接口。

CDN边缘节点可以复用到源站的连接，减少重复TCP和TLS握手。但能否获得实际收益，还要看源站是否支持长连接、连接池是否合理，以及CDN回源连接是否稳定。

网络路径优化

部分CDN的动态加速产品会根据实时网络质量选择边缘到源站的传输路径，绕开拥塞或质量较差的公网路由。

这类能力不能只看节点地图或产品说明。必须在真实用户地区测试，因为不同国家、运营商和时间段的效果可能不同。

协议与传输优化

用户到边缘节点可以使用HTTP/2或HTTP/3，边缘到源站则根据服务能力选择合适协议。对于移动网络、跨境线路和存在丢包的环境，协议与连接管理可能影响请求稳定性。

但协议名称本身不能证明接口一定更快。源站应用处理用了两秒，再快的握手也无法把这两秒消除。

安全防护

API经过CDN后，可以在源站前增加：

• DDoS防护；

• WAF规则；

• Bot管理；

• IP和地区限制；

• 请求频率限制；

• 异常请求识别；

• TLS证书管理；

• 源站IP隐藏；

• 边缘鉴权。

这些能力解决的是安全和可用性，不等同于缓存。一个支付接口不适合缓存，却依然可能需要CDN的抗攻击和访问控制能力。

哪些API比较适合缓存

判断一个接口能不能进入CDN共享缓存，可以先问三个问题。

相同请求是否应该得到相同结果

如果来自不同用户的相同请求，在某段时间内应该得到相同响应，就具备缓存的基本条件。

比较常见的包括：

• 公开文章列表；

• 新闻详情；

• 商品分类；

• 不包含个人价格的商品详情；

• 城市、国家和地区列表；

• App版本信息；

• 公开活动配置；

• 无用户差异的排行榜；

• 允许短暂延迟的统计数据；

• 公共文件元数据；

• 不包含个人状态的搜索热门词。

例如：

GET /api/v1/articles/123
GET /api/v1/categories
GET /api/v1/app/version

这些接口如果一分钟内变化不大，可以设置几十秒到几分钟的共享缓存。

数据能否接受短时间不是最新

缓存意味着在有效期内可能返回稍早的数据。

一篇文章修改后晚30秒生效，通常问题不大；库存只剩一件时，继续返回几分钟前的数量就可能导致超卖。

可以接受多长时间的旧数据，应该由业务决定，而不是CDN工程师凭经验统一设置。

响应中是否包含用户身份或敏感信息

只要响应中包含下面这些内容，就不能在没有严格隔离的情况下进入共享缓存：

• 用户姓名、邮箱、手机号；

• 登录状态；

• 订单和物流信息；

• 账户余额；

• 会员等级；

• 私人消息；

• 权限范围；

• 个性化价格；

• 内部管理数据；

• 与Token绑定的内容；

• 医疗、金融或其他敏感信息。

CDN是共享缓存。规则配置错误时，最严重的问题不是用户看到旧数据，而是用户A的响应被返回给用户B。

哪些API通常不应该进入共享缓存

以下接口一般应该默认排除，除非经过了非常谨慎的架构设计和安全审查。

登录、注册和验证码接口

POST /api/login
POST /api/register
POST /api/send-code

这些请求包含凭证、验证码或身份状态，不能让共享缓存保存和复用响应。

用户资料和账户接口

GET /api/me
GET /api/account/balance
GET /api/orders

即使使用GET方法，也不代表响应适合缓存。HTTP方法只是判断条件之一，真正关键的是内容能否被不同用户共享。

写入和状态变更接口

POST /api/orders
PUT /api/profile
PATCH /api/cart
DELETE /api/address/123

创建订单、更新资料、修改购物车和删除记录等请求会改变服务器状态，通常应直接到达应用服务。

强实时数据

例如：

• 支付结果；

• 库存扣减；

• 实时竞价；

• 秒杀资格；

• 交易价格；

• 风控决策；

• 在线状态；

• 权限变更结果。

这些接口即使是GET请求，也不应因为追求命中率而牺牲数据正确性。

返回结果与用户身份相关的接口

有些接口路径完全相同，但会根据Authorization、Cookie或会话返回不同内容：

GET /api/dashboard
Authorization: Bearer user-token

如果缓存键没有正确区分用户，可能发生严重的信息泄露；如果把完整Token加入缓存键，又会让每个用户产生独立缓存对象，命中率接近于零，还增加缓存管理成本。

这类接口通常更适合不缓存，只使用动态加速和安全能力。

GET接口不等于一定能缓存，POST也不等于完全不能过CDN

“GET缓存、POST不缓存”可以作为初步排查规则，但不能作为最终判断。

大多数CDN默认主要缓存GET和HEAD响应，POST、PUT、PATCH和DELETE通常直接回源。然而，GET请求也可能包含私人数据、实时数据或一次性结果，同样不能共享缓存。

例如：

GET /api/user/profile
GET /api/order/status?id=10001
GET /api/private/download-url

它们虽然是GET，仍然可能与特定用户或实时状态有关。

另一方面，POST请求完全可以经过CDN做动态加速、安全检查和限速，只是不应该在不清楚语义的情况下缓存其响应。

GraphQL尤其容易被误判。很多GraphQL查询通过同一个POST地址提交，请求正文决定查询内容。CDN如果只按URL建立缓存键，就无法区分不同查询。可以通过持久化查询、GET查询或边缘逻辑优化一部分公共请求，但必须把查询内容、变量、身份信息和权限边界设计清楚。

不要为了让GraphQL“可以被CDN缓存”，把复杂请求强行改成GET而忽略URL长度、敏感参数和缓存键安全。

Cache-Control应该怎么设置

API是否缓存，最好由源站明确返回Cache-Control，不要完全依赖CDN猜测。

公共接口短时间缓存

假设一个公开商品分类接口允许CDN缓存两分钟，浏览器只缓存30秒，可以设置：

Cache-Control: public, max-age=30, s-maxage=120

其中：

• public表示响应允许被共享缓存保存；

• max-age=30主要定义客户端缓存的新鲜时间；

• s-maxage=120用于共享缓存，通常会覆盖共享缓存对max-age的使用。

具体行为还要结合CDN规则核对。托管CDN可能允许通过控制台覆盖源站响应头，因此不能只查看应用代码。

私人响应只允许浏览器保存

如果响应属于单个用户，不应该被CDN共享，可以使用：

Cache-Control: private, no-cache

这里的private表示响应只能进入私人缓存，例如用户自己的浏览器缓存，不能进入CDN等共享缓存；no-cache并不是“完全不保存”，而是再次使用前需要向服务器验证。

MDN的HTTP缓存说明特别区分了私人缓存和共享缓存，也说明了个性化响应意外进入共享缓存可能造成信息泄露。

不允许任何缓存保存

对于非常敏感或者不应该存储的响应，可以使用：

Cache-Control: no-store

no-store才表示缓存不应保存该响应。

很多开发者会把下面两个指令混为一谈：

Cache-Control: no-cache
Cache-Control: no-store

它们并不等价：

更完整的语义可以参考MDN的Cache-Control文档以及HTTP缓存标准RFC 9111。

API缓存时间应该设置多久

没有一套适用于所有接口的TTL。

可以按照数据允许的陈旧程度划分：

短TTL并不代表绝对安全。即使只缓存一秒，如果缓存键把用户身份忽略了，也可能把错误响应返回给其他用户。

缓存设计的第一优先级应该是正确性与隔离，第二才是命中率和速度。

stale-while-revalidate能解决什么问题

一些公共API既希望响应快，又能接受短时间旧数据，可以考虑：

Cache-Control: public, s-maxage=60, stale-while-revalidate=30

这表示共享缓存中的响应在60秒内是新鲜的；过期后的一个短窗口内，可以先返回旧内容，同时在后台更新缓存。

它适合：

• 新闻列表；

• 公开商品目录；

• 推荐内容；

• 公共配置；

• 非实时统计。

它不适合余额、支付状态、实时库存等必须准确的接口。

还可以评估stale-if-error，在源站临时故障时返回一份旧的公共数据。不过，不同CDN对这些指令的支持和覆盖规则可能不同，必须以当前官方文档和实际测试为准。

返回旧数据也不一定总比报错好。错误的价格、权限或业务状态可能带来更大损失。

缓存键才是API缓存最危险的地方

CDN收到请求后，需要判断它与之前的请求是不是同一个缓存对象。用于区分缓存对象的规则，就是缓存键。

常见组成包括：

• 域名；

• URL路径；

• 查询参数；

• 请求方法；

• 部分请求头；

• Cookie；

• 设备或地区信息。

查询参数不能全部忽略

下面几个请求返回的内容显然不同：

/api/products?page=1
/api/products?page=2
/api/products?page=1&sort=price
/api/products?page=1&category=server

如果CDN忽略全部查询参数，它们可能被当成同一个缓存对象。

但如果把所有参数都纳入缓存键，下面这些无关参数又可能制造大量重复缓存：

?utm_source=google
?request_id=随机值
?timestamp=每次变化

更合理的做法是建立参数白名单，只让真正改变响应内容的参数进入缓存键。

Amazon CloudFront的查询参数缓存文档也建议根据源站实际使用的参数配置缓存行为，避免不必要的参数变化降低缓存命中率。

不要随意忽略Authorization和Cookie

假设接口根据Token返回不同用户信息：

GET /api/profile
Authorization: Bearer token-a

如果缓存键忽略Authorization，Token A请求生成的响应可能被Token B命中。

但把每个Token完整加入缓存键也不一定是好办法。它会产生大量几乎无法复用的缓存对象，还可能在日志和调试系统中增加敏感信息暴露风险。

对于用户私有接口，通常更稳妥的方案是不使用共享缓存。

Vary不能无限增加

如果响应会根据语言变化，可以返回：

Vary: Accept-Language

这样不同语言会形成不同缓存版本。

但如果使用：

Vary: User-Agent

由于User-Agent种类非常多，缓存对象可能被严重切碎。MDN的Vary文档说明了响应选择与请求头之间的关系。实际使用时，应只加入真正影响响应内容且取值相对可控的请求头。

API缓存最常见的几类事故

用户A拿到用户B的数据

原因通常是：

• 私人接口被设置成公共缓存；

• 缓存键忽略了身份信息；

• 登录和未登录响应使用相同缓存键；

• CDN“缓存所有内容”规则覆盖了源站的私人缓存设置。

这是API缓存中最严重的一类问题。上线前必须使用不同账户交叉测试，不能只看自己的账户是否正常。

修改数据后仍然看到旧结果

例如用户修改头像、管理员更新文章、商品下架后，读取接口仍返回旧缓存。

解决方式可能包括：

• 缩短TTL；

• 写入成功后主动刷新对应URL；

• 使用版本号；

• 将强实时字段与可缓存字段拆分；

• 在响应中标注数据生成时间；

• 建立可靠的缓存失效事件。

最难的不是设置缓存，而是确保数据更新时知道应该清除哪些缓存对象。

参数不同却返回相同结果

通常是查询参数没有进入缓存键，或参数排序、大小写和编码规范化不一致。

测试时不能只请求一个固定URL。分页、筛选、语言、地区、设备和版本参数都要分别验证。

缓存命中率很低

可能原因包括：

• 每个请求都带随机参数；

• 完整Cookie或Token进入缓存键；

• Vary维度过多；

• TTL太短；

• 接口URL设计不稳定；

• 响应头禁止缓存；

• 不同节点之间缓存过于分散。

命中率低不一定说明CDN无效，但说明“缓存减轻源站压力”这一目标没有实现。

短TTL到期时源站突然被打满

热门接口缓存同时过期，大量节点一起回源，会形成缓存击穿或惊群。

可以评估：

• 缓存过期时间增加适度随机量；

• 请求合并；

• 分层缓存或Origin Shield；

• stale-while-revalidate；

• 热点接口预热；

• 源站限流和降级；

• 热点数据在应用层缓存。

CDN缓存不能代替应用自身的容量设计。

动态API应该怎么测速

测试动态API时，不能把缓存HIT和回源结果混在一起。

至少应建立三组结果：

1. CDN缓存HIT；

2. CDN缓存MISS或需要重新验证；

3. 完全不缓存、每次回源的动态请求。

先查看响应头和请求耗时

可以使用curl：

curl -sS -D - -o /dev/null \
  -w 'remote_ip=%{remote_ip}\nhttp_code=%{response_code}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n' \
  'https://api.example.com/api/v1/categories'

连续执行几次，记录：

• 响应IP；

• HTTP状态码；

• Cache-Control；

• Age；

• ETag；

• Vary；

• CDN缓存状态头；

• DNS、连接、TLS、TTFB和总耗时。

如果第二次明显更快，同时缓存头从MISS变成HIT，说明缓存可能发挥了作用。但不能仅凭速度变化判断，仍要结合响应头和源站日志。

不要用随机参数测试缓存命中

如果每次请求都增加：

?timestamp=随机时间

而CDN又把这个参数纳入缓存键，每次都会形成新的缓存对象。这样测到的可能永远是MISS。

测试HIT时，URL、参数和相关请求头必须保持一致。

测试不同参数是否正确隔离时，再分别请求：

/api/products?page=1
/api/products?page=2
/api/products?page=1&sort=price

比较响应内容和缓存状态。

用两个测试账户检查是否串数据

在经过授权的测试环境中，分别使用账户A和账户B请求同一个私人接口：

curl -sS \
  -H 'Authorization: Bearer TEST_TOKEN_A' \
  'https://api.example.com/api/me'

然后使用账户B：

curl -sS \
  -H 'Authorization: Bearer TEST_TOKEN_B' \
  'https://api.example.com/api/me'

需要核对：

• 两个账户返回的数据是否正确；

• 私人响应是否出现缓存HIT；

• CDN是否忽略了身份信息；

• 响应头是否包含private或no-store；

• 源站日志是否收到对应请求。

测试只能使用专用测试账户和临时Token，不能把真实Token写入公开脚本、文章或日志。

测动态加速时要排除缓存影响

如果要判断CDN的动态链路是否有效，应选择明确不缓存的接口，分别测试：

• 用户直接或通过专用测试入口访问源站；

• 用户通过CDN访问同一源站；

• 不同地区、运营商和时间段；

• 单次请求与持续请求；

• P50、P95和错误率。

不要把CDN的缓存HIT拿来对比源站实时计算结果，那是在比较缓存和应用执行，而不是比较动态传输路径。

直接测试源站时，不应该为了方便把真实源站IP公开暴露。可以使用受限测试域名、临时白名单或内部探针完成对比。

为什么API测速要看P95，而不只是平均值

假设100次API请求中，90次在200毫秒内完成，10次超过3秒。平均值可能仍然看起来可以，但真实用户会频繁感受到卡顿。

动态API尤其要关注：

• 成功率；

• P50；

• P75；

• P95；

• P99；

• 超时比例；

• 5xx比例；

• 不同地区的最慢请求；

• 缓存HIT和MISS差距；

• 高峰时段变化。

平均值容易把慢请求摊平。对于登录、搜索、提交表单和移动端接口，长尾延迟通常比一次最快成绩更值得关注。

可以通过CDNChart网站测速观察不同地区访问API URL时的基础链路、TTFB和可用情况，再结合应用监控、CDN日志和真实用户数据定位瓶颈。

关于持续采样的方法，可以参考《网站有时快有时慢，CDN测速应该怎么测》。

API慢了，怎么判断是CDN还是源站

可以按照缓存状态分开排查。

HIT很快，MISS很慢

说明边缘缓存交付正常，问题更可能出在：

• CDN回源线路；

• 源站应用处理；

• 数据库查询；

• 第三方接口；

• 源站连接池；

• 冷数据加载；

• 缓存重建。

HIT和MISS都慢

可能需要检查：

• 用户是否被调度到较远节点；

• 当前运营商到节点的网络质量；

• CDN节点处理延迟；

• WAF或边缘函数耗时；

• 响应体是否过大；

• 接口是否发生多次重定向；

• 客户端自身处理时间。

绕过CDN快，经过CDN慢

说明CDN可能增加了额外路径或处理开销。重点检查：

• 节点调度；

• 回源区域；

• WAF规则；

• 边缘函数；

• TLS和协议设置；

• 回源连接复用；

• CDN到源站的路由；

• 是否出现不必要的请求改写。

CDN和源站都慢

如果直接访问源站和通过CDN都慢，通常不能只调整CDN。应该继续查看应用执行时间、数据库、缓存服务、内部RPC和第三方依赖。

相关判断方法可以参考《TTFB高是什么原因？CDN和源站应该先查谁》。

选择API CDN时，应该比较哪些能力

动态API选CDN，不能只看静态文件命中率。

需要WebSocket或gRPC时尤其要先确认产品支持范围。某个CDN支持普通HTTP API，不代表它的所有节点、套餐和安全规则都适合长连接或流式通信。

动态API接入CDN的稳妥顺序

不要一开始就对整个/api/目录启用“缓存所有内容”。

更安全的实施方式是：

1. 列出所有API路径、方法、身份要求和数据敏感级别；

2. 将接口分为公共可缓存、公共不可缓存、用户私有和写入操作；

3. 默认不缓存，只对白名单接口逐个开放共享缓存；

4. 为每个可缓存接口确定允许陈旧的时间；

5. 明确定义查询参数、Header和Cookie如何进入缓存键；

6. 设置准确的Cache-Control、Vary和验证头；

7. 使用不同账户、语言、地区和参数进行交叉测试；

8. 分别记录HIT、MISS和不缓存请求的性能；

9. 建立数据更新后的缓存失效流程；

10. 小流量灰度上线，持续观察错误率、命中率和源站负载；

11. 确认没有用户数据、Token或私人响应进入共享缓存；

12. 再逐步扩大到其他适合缓存的接口。

如果某个接口的共享边界说不清楚，先不要缓存。它仍然可以接入CDN做动态加速和安全防护。

常见问题

动态API经过CDN后，会不会自动被缓存？

通常不会因为“经过CDN”就必然缓存。是否缓存取决于请求方法、状态码、响应头、CDN默认规则和自定义缓存配置。不过，不能只依靠默认行为，关键接口应该明确设置缓存策略并实际验证。

API返回JSON，可以被CDN缓存吗？

可以。是否能缓存与返回的是JSON、HTML还是其他格式没有直接关系。关键是响应能否被多个用户安全共享，以及允许多长时间不是最新数据。

带Authorization的接口能缓存吗？

技术上可以设计非常复杂的缓存策略，但风险较高。用户私有响应通常不适合共享缓存。不能简单忽略Authorization，也不建议为了命中率把不同用户的私人响应合并。

POST接口可以使用CDN吗？

可以经过CDN做动态加速、WAF、限速和DDoS防护，但大多数CDN默认不会缓存POST响应。创建订单、登录、支付和修改数据等操作也不应该为了加速而共享缓存。

API设置了no-cache，为什么CDN里还有记录？

no-cache并不表示不能保存，而是复用前需要重新验证。如果不希望任何缓存保存响应，应评估no-store。同时还要检查CDN是否存在覆盖源站响应头的自定义规则。

API缓存时间越长，速度是不是越快？

缓存时间长可能提高命中率，但也会增加旧数据存在的时间。TTL应该由业务对数据新鲜度的要求决定，而不是单纯追求更高的HIT比例。

动态加速一定比直接访问源站快吗？

不一定。如果用户和源站距离很近、源站网络质量很好，CDN增加的处理层可能没有明显收益。跨地区、跨运营商或跨境访问更可能受益，但仍然需要用真实地区的P50、P95、错误率和稳定性验证。

API接入CDN后，还需要应用层缓存吗？

通常仍然需要。CDN缓存适合减少重复的公共请求，应用层缓存则可以减少数据库查询、内部RPC和业务计算。两者处于不同位置，不能完全互相替代。

动态API是否适合使用CDN，答案并不是简单的“适合”或“不适合”。

公共、可共享并允许短时间陈旧的响应，可以考虑CDN缓存；用户私有、强实时和写入类接口通常不进入共享缓存，但仍然可以使用动态加速和安全能力。真正需要避免的，不是动态API经过CDN，而是在没有划清用户边界、缓存键和数据时效之前，就对整个API域名开启统一缓存。