CDN缓存怎么设置？静态资源、登录页面与缓存更新实用指南
CDN缓存设置的第一步，是区分哪些内容所有用户看到都一样，哪些内容会随账号、权限或实时状态变化。前者适合缓存，后者需要更严格的边界。将整个网站统一缓存很久，可能让内容更新延迟，甚至把个性化页面错误地提供给其他访客。
浏览器缓存与CDN缓存是两层
浏览器缓存保存在访客设备上，CDN缓存通常由多个访客共享。清理CDN缓存，并不会自动清掉已经进入用户浏览器的旧副本。排查“更新不生效”时，应分别检查浏览器、边缘节点和源站，避免反复重启应用。
HTTP响应头可以表达缓存意图，但供应商控制台规则可能覆盖或补充源站行为，因此需要核对优先级。不能把一家CDN的默认策略直接套给另一家。Cloudflare默认缓存说明就单独列出了默认缓存条件，说明接入代理不等于所有响应都会缓存。
为不同内容设定不同策略
| 内容 | 起步策略 | 验收重点 |
|---|---|---|
| 带版本或内容哈希的CSS、JS、图片 | 较长缓存，新版本使用新URL | 页面引用的新资源确实存在 |
| 新闻、教程等公开HTML | 根据更新频率选择短缓存或重新验证 | 修改后能在预期时间看到新内容 |
| 登录后页面、订单、账号资料 | 禁止共享缓存；敏感内容通常使用no-store | 不同账号之间不能相互看到内容 |
| 搜索结果与公开API | 单独评估参数、成本和时效后再启用 | 缓存键完整，错误响应不会长期保留 |
缓存时间不需要照抄一个“最佳值”。例如，一篇每月修订一次的教程与库存页面，对陈旧信息的容忍度完全不同；先明确允许延迟多久，再填写TTL，才有验收标准。
看懂常用缓存指令
max-age描述缓存新鲜期；s-maxage面向共享缓存，可让边缘与浏览器采用不同的时效。no-cache允许存储，但再使用前必须向服务器验证；no-store要求不存储。private表示响应不能被共享缓存存储，但仍可能由浏览器私有缓存保留。这些含义可查阅MDN Cache-Control参考。
不要因为名字带“no-cache”就认为内容完全没有被保存。也不要只看Cookie是否存在来推断CDN一定不会缓存：自定义“缓存全部”规则、边缘脚本和供应商差异都可能影响最终结果。对于已经误缓存的敏感响应，还需停用相关规则并清除已有副本，单独修改响应头不足以处理已泄露的问题。
缓存键决定两个请求能否共用内容
同一个路径如果按语言、币种或查询参数生成不同内容，缓存键就需要表达这些差异。忽略查询参数可以提高命中率，但也可能将不同搜索条件的结果混在一起；保留所有追踪参数，则可能制造大量重复副本。
处理前先列出真正改变内容的参数。页面若使用Vary区分响应，还需确认CDN是否支持对应维度。不要把用户令牌随意放进可共享的缓存设计中；私人页面通常应直接绕过共享缓存，而不是尝试用复杂规则勉强隔离。MDN缓存指南解释了这些缓存层与验证机制。
接入时按小范围验证
先选择一个公开、无账号信息的静态资源路径启用规则。请求两次，检查供应商的命中标记、Age以及源站日志；第二次仍未命中时，再排查缓存条件、响应头、查询参数、Cookie和边缘规则。不同节点第一次访问出现未命中，并不必然表示配置失效。
使用浏览器开发者工具检查响应头时，注意“禁用缓存”选项只影响当前测试方式，不能代表普通访客的情况。对同一资源分别测试正常访问、无痕访问及发布新版本后的访问。若无法从响应头确认命中情况，应以供应商日志和源站请求变化共同判断。
发布新内容时准备更新与回退
带内容哈希的资源适合使用新文件名发布；HTML则根据缓存策略刷新或等待验证。清理缓存后流量会重新到达源站，热门网站应分批更新并观察回源负载。回退时还要确认旧HTML引用的旧资源没有提前删除。
最后用两个测试账号分别访问账户页、退出再进入，并验证商品、登录与表单等动态流程。一个合格的缓存配置，应同时满足内容正确、账号隔离和更新可控，再去优化命中率和源站成本。