如果你正在处理CDN Purge，先别急着照搬网上的参数。当你把网站接入CDN后，用户访问到的静态资源（图片、CSS、JS等）会被缓存在全球边缘节点上。这样确实能大幅提升加载速度，但也带了一个现实问题：如果源站已经更新了文件，用户可能还在用边缘节点上的旧版本缓存。解决这个问题的操作就是“缓存刷新”（Cache Purge）。
缓存刷新的本质是让CDN节点主动丢弃指定的缓存文件，下次用户请求时重新从源站拉取最新内容。但刷新方式选不对，要么效率极低（比如一把清空整个站点缓存，导致大量回源请求压垮源站），要么操作繁琐（需要手动列出成千上万个URL）。因此，CDN厂商推出了智能刷新方式：Purge by Tag（按标签刷新）和Purge by Prefix（按前缀刷新）。本文就带你从头理解这两个概念，以及它们如何帮你精准、高效地更新缓存。
为什么传统刷新方式不够用？
在说智能刷新之前，我们先看看传统刷新做了什么，痛点在哪。
全量刷新（Purge All）
顾名思义，让CDN节点清除所有缓存文件。听起来简单粗暴，但问题很明显：
- 造成大量非必要回源，正常的缓存也被清掉，CDN加速效果瞬间归零；
- 回源流量激增，如果源站带宽不够，反而拖慢全站；
- 操作不可控，你只想更新一张图片，却让所有用户都重新请求一遍首页的CSS。
全量刷新只适合极端场景（例如源站被篡改后紧急恢复），日常运维中基本是“核武器级别”的选项。
精确URL刷新（Purge by URL）
只刷新指定的某个或某几个URL的缓存。比如你改了一张图片 https://cdn.example.com/image.png，那就只刷新这个URL。这样做最精准，但弊端也很明显：
- 如果一次更新了几百个文件，你得一个一个提交URL，手动操作费时费力；
- 很多场景下你并不知道所有变化文件的完整URL（比如后端动态生成的文件名带版本号）。
精确刷新适用于“小改小补”，但当资源数量和更新频率上升时，它就成了运维人员的噩梦。
于是，智能刷新应运而生：你不需要知道每个具体URL，也不需要全盘清空，而是通过“标签”或“路径前缀”来描述一类资源，然后按类清除。这就是Purge by Tag和Purge by Prefix。
补充参考：此处可内链到“CDN Purge故障排查实例”。
Purge by Tag：按标签刷新
想象一下，你有一个图书馆，每本书的侧面贴了不同颜色的标签：红色代表小说，蓝色代表历史，绿色代表科学。当小说区域要换一批新书时，你只需要说“把红色标签的书全部下架”，而不用一本本去查书名。Purge by Tag的工作原理与此类似。
原理与实现
CDN厂商允许你在向边缘节点推送资源（或用户首次请求时回源）时，给HTTP响应头加上自定义的标签。比如一个常见的实现是在源站返回的响应头中增加：
Cache-Tag: product-v2, homepage-2025这意味着这个资源被打上了“product-v2”和“homepage-2025”两个标签。你可以为不同业务、不同版本、不同模块的资源打上不同的标签。之后，当你通过CDN控制台或API提交一个刷新请求时，输入product-v2这个标签，所有携带该标签的缓存都会在边缘节点被清除。
适用场景
- 版本化资源更新：比如你的网站升级了V2版本，所有相关的JS/CSS/图片都打上
v2标签，上线时刷新一次这个标签搞定。 - 热点活动下架：双11活动结束后，只需刷新“activity-2025-11”标签下的所有资源，不用手动梳理活动页用到的1000多张图片。
- 精细化运营：不同用户群体的资源打上不同标签（如
user-premium），实现了定向刷新。
如何设置？
不同的CDN服务商实现略有差异，但通用的流程是：
- 在源站服务器配置中，为需要打标签的响应（如静态文件返回）增加
Cache-Tag响应头，或者通过CDN平台的“回源改写响应头”功能自动给资源打标。 - 在CDN控制台的缓存刷新功能中，选择“按标签刷新”，输入标签名称（支持一次输入多个，用逗号或换行分隔）。
- 提交后，CDN内部会查询元数据，找出哪些URL携带了这个标签，然后对这些URL的缓存执行清除。
注意： 标签的设计要遵循CDN厂商的规则（通常是大小写敏感、不支持特殊字符）。另外，打标操作必须发生在资源首次被缓存之前，否则已经缓存的资源没有标签信息，刷新时识别不到。
相关阅读：此处可内链到“CDN Purge常见问题”专题。
关联教程：此处可内链到“CDN Purge部署与验证”内容。
进阶阅读：此处可内链到“CDN Purge性能优化”指南。
Purge by Prefix：按前缀刷新——CDN Purge
如果你的资源组织结构良好，比如所有用户头像都放在 /static/avatars/ 目录下，所有商品图片放在 /static/products/ 下，那么按路径前缀刷新就非常方便。
原理与实现
Purge by Prefix允许你输入一个URL路径前缀（例如 http://cdn.example.com/static/products/），然后CDN会清除所有以该前缀开头的缓存文件。它并不关心资源有没有打标签，而是直接根据URL的字符串匹配来操作。
这相当于说：“请把 /static/products/ 目录下的所有文件缓存都扔掉”。在大多数CDN系统中，前缀刷新支持“通配符”或“目录级”的清除，但注意它和正则表达式不同，只匹配前缀，不匹配中间任意部分。
适用场景
- 批量替换目录资源：比如今天把整站商品图片全部替换为WebP格式，可直接刷新
/static/products/前缀，不必逐个改图片名。 - 静态站改版：你的博客将
/posts/目录下的所有文章HTML都重写了？刷新这个前缀。 - API接口缓存清理：如果CDN前面还缓存了某些API JSON（例如
/api/search/），但搜索索引更新，可以刷新这个前缀。
如何设置？
通常直接在CDN控制台的“按前缀刷新”（或“目录刷新”）输入框里填写完整前缀即可。例如：
https://cdn.example.com/static/2025/注意：有些CDN要求必须以http://或https://开头，并且要包含域名；有些只需要路径（如/static/2025/），具体看平台文档。
Purge by Tag vs Purge by Prefix：怎么选？
我的处理经验
两者并不互斥，甚至可以结合使用。但为了让你快速决策，我整理了一个对比表：
| 维度 | Purge by Tag | Purge by Prefix |
|---|---|---|
| 依赖条件 | 资源必须提前打标签（额外配置） | URL路径有规律即可，无需预配置 |
| 灵活性 | 高，可跨目录、跨域名聚合刷新 | 低，只能按路径前缀线性匹配 |
| 适用场景 | 资源分散、按逻辑更新（版本、活动、用户组） | 资源按目录组织、按目录更新 |
| 操作复杂度 | 需要源站配合加响应头或CDN规则 | 无需额外配置，直接填写路径 |
| 精确度 | 可以非常细（一个标签对应几百个URL） | 可能会误刷（如果错误地用了太短的前缀） |
简单建议： 如果你有完善的CI/CD流程，能方便地在构建时打标签，推荐用Tag。如果你只是手动更新一个目录下的文件，或者CDN不支持Tag功能，Prefix是最好的替代。两者也能同时使用——比如先按Tag刷新主要资源，再用Prefix补刷遗漏。
延伸阅读：此处可内链到“CDN Purge配置案例”相关文章。
实际操作中的注意事项
无论用Tag还是Prefix，以下问题都值得留意：
1. 标签设计要规范
不要使用不明确的标签名如 img（会刷掉所有图片），建议包含版本、模块、环境等信息，如 prod-v2-product。同时注意标签数量限制，某些CDN每个资源最多支持10个标签。
2. 前缀长度要合理
前缀太短（如 /）等于全量刷新，太长了又失去批量能力。建议以业务目录为粒度，例如 /static/js/v2/ 而非 /static/。
3. 验证刷新结果
刷新提交后，CDN不会立即在所有边缘节点生效（会有秒级到分钟级的延迟）。你可以通过curl对比刷新前后的响应头x-cache或age字段来确认。一些CDN平台提供“刷新历史”或“刷新进度”查询。
4. 避免频繁刷新
每次刷新都会产生回源请求，频率过高会消耗源站资源。建议将标签或前缀的变更和上线流程绑定，例如每次发布脚本自动触发一次刷新，而不是手动频繁操作。
5. 注意不同CDN平台差异
各厂商对Tag和Prefix的支持程度不同，比如有些同时支持“按主机名”刷新，有些支持“按正则”刷新。在切换CDN服务商时，一定要重新梳理刷新策略。
总结：从“刷新焦虑”到“刷新自由”——CDN Purge
容易忽略的细节
对于刚开始接触CDN的站长或开发者来说，缓存刷新可能是个头疼的问题：既不想让用户看到旧内容，又不敢随便全量刷新。Purge by Tag和Purge by Prefix恰好提供了两把精准的手术刀——前者适合按业务逻辑清理，后者适合按目录结构清理。理解它们背后的思想后，你就能根据自己网站的资源组织方式和更新频率，设计出最合适的刷新方案。
其实，缓存刷新只是CDN运维中的一个环节。当你开始用Tag或Prefix管理缓存时，你会发现它和版本控制、自动化部署能很好地结合。真正的高手，会用这几个简单的操作，让用户在毫秒级体验最新内容，而源站几乎感受不到刷新带来的压力。希望这篇文章能帮你迈出第一步。按这个顺序复查，CDN Purge遇到异常时也更容易定位。
延伸阅读