刷新缓存没有统一的“多久生效”数字：URL 刷新、目录刷新、预热走的是不同队列，返回给你的只有任务 ID 和状态字段。能立刻判断的是三件事——提交是否被受理、任务状态是否走完、边缘节点拿到的响应头是否已经变了。想得到一个可复用的结论，得把这三件事分开核对，而不是只盯控制台里那行“已完成”。
CDN 刷新缓存的时长取决于刷新类型、当前刷新队列和缓存键规则，没有跨厂商通用的分钟数。可以先提交单条 URL 刷新拿到任务 ID，再按状态字段轮询到结束；随后用带随机参数的 curl 看 Age 是否归零、X-Cache 是否变为回源。风险边界在于：任务完成只表示刷新指令执行完，不代表所有地区、所有中间层和用户浏览器都已换新，配额与单次提交条数要以各厂商刷新接口文档和控制台配额页为准。
刷新缓存需要多久：先把能核对的事实摆清楚
要判断时长，先把你手里的对象分清楚：刷的是一个 URL、一个目录，还是提前预热。URL 刷新只影响精确匹配的缓存键；目录刷新影响该路径下的对象，但在多数厂商那里是异步批量执行；预热是主动把源站内容推到节点，方向和刷新相反，耗时也不一样。
前提条件同样要确认：缓存键是否包含 query string。如果 CDN 的缓存键规则里带上了查询参数，那么带参数和不带参数就是两个不同的缓存对象，刷新其中一个不会影响另一个。这条规则的位置在 CDN 控制台的“缓存配置/缓存键”页，或者在域名配置的缓存规则里，先看清楚再提交。
可核对的东西只有几类：接口返回的刷新任务 ID；控制台“刷新预热”记录页里的状态列；CDN 响应头里的 Age、X-Cache、CF-Cache-Status、Via 这类字段。任务 ID 和状态列是可追溯的事实，页面上那句“刷新成功”只是任务层面的结论。
配额、单次提交条数、每日刷新上限、是否支持按目录刷新，这些会随套餐和厂商政策变化，不要凭记忆写死。查的位置是两处：各厂商 CDN 刷新接口文档的参数说明页（如阿里云 RefreshObjectCaches、腾讯云 PurgePathCache、Cloudflare 的 purge_cache），以及控制台刷新预热页上的配额提示。
刷新缓存需要多久最容易搞错的一点
最常见的误解，是把“刷新任务状态变成完成”直接等同于“用户已经拿到新文件”。刷新任务完成只说明这条指令在 CDN 侧执行完毕；真正决定用户看到什么版本的，还有源站缓存、中间层缓存和浏览器本地缓存。三者任意一环没换，页面看起来就像没刷成功。
判断分界放在缓存键和 Age 上：如果响应头里的 Age 是个明显大于零的值，说明命中的还是旧缓存副本；如果是首次回源，通常会看到 X-Cache: MISS 或等价字段，紧接着第二次请求才转为 HIT。
能把两种情况区分开的检查动作是：从同一台机器分别请求带随机参数和不带参数的地址，各看一次响应头。
curl -sI "https://static.example.com/app.js" | grep -iE "^(age|x-cache|cf-cache-status|via|etag|last-modified)"
curl -sI "https://static.example.com/app.js?ts=$(date +%s)" | grep -iE "^(age|x-cache|cf-cache-status|via|etag|last-modified)"如果带随机参数的那次返回了新内容、不带参数的那次还是旧 ETag，问题在缓存键或刷新对象不匹配，不是“刷新还没到时间”。如果两次都是新的，但同事那边还是旧的，大概率是浏览器本地缓存或中间层，去让对方用无痕窗口再确认一次。
刷新缓存需要多久：一个照着就能做完的做法
以单条 URL 刷新为例，下面给出阿里云 CLI、腾讯云 CLI 和 Cloudflare API 三种写法，按你实际使用的厂商选一段执行。执行前先把域名、路径、凭证替换成自己的，命令在本地终端或跳板机上跑，不要在浏览器控制台里跑。
第一步，提交刷新并记下任务 ID。阿里云：
aliyun cdn RefreshObjectCaches \
--ObjectPath "https://static.example.com/app.js" \
--ObjectType File返回结果里会有 RefreshTaskId 字段，复制出来存到变量里。这一步该看到的是任务 ID，如果返回权限错误或参数错误，说明凭证或 ObjectType 写错了，先改这个再看下一步。
腾讯云：
tccli cdn PurgePathCache \
--Paths '["https://static.example.com/app.js"]' \
--FlushType flush返回里取 PurgeTaskId。注意 FlushType 的取值和文件/目录刷新的对应关系，以 PurgePathCache 接口文档的参数说明为准。
Cloudflare：
curl -s -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/purge_cache" \
-H "Authorization: Bearer $CF_TOKEN" \
-H "Content-Type: application/json" \
--data '{"files":["https://static.example.com/app.js"]}'返回体里 success 为 true 表示请求被受理。单次请求能带多少条 URL、按标签刷新的用法，以 purge_cache 接口文档为准。
第二步，轮询任务状态直到结束。阿里云可以这样看：
aliyun cdn DescribeRefreshTasks --TaskId "$TASK_ID" \
| jq -r '.Tasks.Task[] | [.ObjectPath, .Status, .Process] | @tsv'正常会依次看到处理中、完成，或者直接变成失败。轮询间隔建议 10 秒左右，别一秒一次，没必要也容易触发接口限流。第三步，回到上面那两条 curl，确认响应头已经变化，再决定要不要通知业务方。
刷新缓存需要多久：怎么验证结果对不对
验证分两层。任务层看状态字段和失败原因；内容层看响应头里的版本标识。任务层在控制台“刷新预热”记录页可以按 URL 搜索，也可以继续用 DescribeRefreshTasks / DescribePurgeTasks 按 TaskId 查；内容层用发起请求的方式确认。
curl -sI "https://static.example.com/app.js?ts=$(date +%s)" \
| grep -iE "^(age|x-cache|cf-cache-status|etag|last-modified|content-length)"正常结果长什么样：第一次请求命中回源，能看到 Age: 0 或很小的值，X-Cache 为 MISS 一类；紧接着再请求一次，变为 HIT，此时 ETag 或 Last-Modified 与源站当前文件一致。如果你对比的是 HTML 入口文件，还应确认引用的是新的静态资源指纹，而不是只换了缓存头。
浏览器侧再补一次：打开开发者工具的 Network 面板，勾选 Disable cache，刷新页面，看目标文件的 Size 列是否显示从网络加载、Response Headers 里的 ETag 是否为新值。对方仍看到旧内容时，先让他用无痕窗口或强刷一次，再回到多看几个不同网络的响应头，别只凭一次访问就断定刷新没生效。
最后一个容易踩的坑：提交刷新时给 URL 拼了随机参数 ?ts=123。如果缓存键包含 query string，这么刷等于刷了一个没人访问的新对象，真实用户请求的那条缓存依然在。刷新时传的路径要和缓存键规则、和真实访问的 URL 保持一致，随机参数只在验证阶段使用。