CDN缓存是指内容分发网络将源站返回的静态或动态响应复制保存到距离用户更近的边缘节点上，后续请求由边缘节点直接返回，从而减少回源延迟与源站负载。当浏览器请求一张图片或一个脚本文件时，请求首先到达CDN边缘，如果缓存中存在且未过期，就直接响应；否则边缘节点再去源站拉取并存储。TTL（Time To Live）则是每条缓存记录的最大存活时长，到期之后边缘节点必须重新验证或回源。TTL设置策略直接决定了网站更新后用户多久能看见新内容，也影响着源站的流量成本。
CDN缓存的基本工作原理与命中流程
当用户发起请求，CDN边缘节点会先解析请求URL、Host以及缓存键（Cache Key）。缓存键通常包含域名、路径和少量参数，边缘节点用这个键在本地存储中查找是否存在对应对象。如果找到且当前时间减去缓存写入时间小于TTL，就判定为命中，直接返回200响应，这个过程不接触源站。命中率越高，源站压力越小，用户延迟越低。
未命中或缓存已过期时，边缘节点会向源站发送请求。源站返回响应后，边缘节点根据响应头中的Cache-Control、Expires或CDN自定义规则计算TTL，并写入本地存储。例如源站返回Cache-Control: max-age=3600，则边缘节点将该对象缓存一小时。需要注意的是，不同CDN厂商对缓存键的默认构造方式不同，有的会把查询字符串纳入键中，有的忽略，这会造成相同的URL在不同配置下命中情况不同。
在多层CDN架构中，还存在父层节点与子层节点，子层未命中可向上级节点请求，只有顶级未命中才回源。这种结构进一步减少跨运营商回源，但也意味着TTL生效具有层级传播性：父层未过期时，子层即使到期也可能从父层拿到旧内容。因此在分析更新延迟时，不能只盯边缘层，还要看整条缓存链路的刷新机制。
TTL设置策略的常见模式与对更新的影响
最常见的策略是为所有资源设置统一TTL，比如全部设为一天。这种做法配置简单，但弊端明显：HTML页面更新缓慢，用户可能长时间看到旧版页面；而极少变动的字体文件却本可以设更长以减少回源，却被一刀切限制。更严重的是，当网站紧急修复了某个JS漏洞，统一TTL导致修复在全球边缘节点上滞后，形成安全风险窗口。
更合理的做法是按资源类型分层。通常HTML设较短TTL（如60秒到300秒），因为页面结构常随发布变化；CSS、JS等带版本号或哈希名的静态文件可设很长（如一周到一月），因为文件名变了就是新资源；图片和字体也可长缓存。这样发布新页面后能较快生效，又不增加静态文件的回源。
另一种策略是结合主动刷新（Purge）接口。运维发布后调用CDN的清除API，按URL或前缀作废缓存，TTL仅作为兜底。示例代码如下，用Python请求某CDN清除接口：
import requests
# 调用CDN提供的清除缓存接口，使指定路径立即失效
api_url = "https://cdn.ipipp.com/api/v1/purge"
headers = {"Authorization": "Bearer secret_token"}
payload = {"files": ["https://www.ipipp.com/index.html",
"https://www.ipipp.com/static/app.js"]}
resp = requests.post(api_url, json=payload, headers=headers)
print(resp.status_code)
该方式的优点是更新即时，缺点是需要发布系统对接，且频繁Purge会产生大量回源。TTL与Purge应配合使用，而非互相替代。
基于业务场景的TTL优化实践与误区
电商类网站在大促前常把商品详情页TTL临时调低，以保证价格变更快速生效；媒体类网站对图片设长TTL并依赖文件名哈希，避免重复传输。错误认知是认为设置了no-cache就绝对不缓存，实际上no-cache只要求使用前重新验证，边缘仍可能缓存对象并与源站校验，和no-store完全不同。混淆这两者会导致本该节省流量的资源被反复回源。
还有一个误区是忽略浏览器缓存与CDN缓存的叠加。即使CDN TTL到期回源拿到新文件，如果用户本地浏览器缓存未过期，依然展示旧图。因此前端构建时应给静态资源加内容哈希名，HTML引用新名即自然更新，不依赖CDN强制过期。如下HTML片段展示了带哈希的引用方式：
<!DOCTYPE html> <html> <head> <link rel="stylesheet" href="/static/app.3f2a9c.css"> <script src="/static/main.8b1e4f.js"></script> </head> <body> <p>页面内容</p> </body> </html>
从架构角度看，TTL设置应写入配置管理系统而非散落在各源站响应头，方便统一审计。可建立一张决策表，明确每类资源的TTL下限与上限、是否允许Purge、是否带版本号。这样既能控制成本，也能让网站更新可预测地到达用户侧，避免出现“源站已发新包，用户还在用旧版”的投诉。