静态资源上 CDN 后的缓存刷新

改了静态资源，用户那边还是旧图旧样式，问题多半出在缓存刷新没做对。刷新和预热是一对方向相反的动作，先分清再用。 一、刷新与预热的区别 刷新是让 CDN 节点丢弃指定 URL 的旧缓存，用户下次访问时节点回源取新的；预热是反过来，提前把源站文件拉到各节点，用户首次访问就命中缓存。更新已发布的文件用刷新；上新活动页面、分发大文件之前用预热，避免开闸瞬间大量回源把源站压垮。两个动作都在 CDN 控制台操作，量大的用接口提交，配合发布流程做成自动化。 二、优先用版本号绕开刷新 最省心的更新方式根本不用刷：改 URL。文件名后面加版本参数 ?v=2，或者构建产物自带内容哈希，比如 app.3f9c2a.js——URL 变了，缓存键就变了，新旧资源各走各的。前端构建工具默认输出带 hash 的文件名，配合 HTML 里更新引用，整套流程没有刷新动作。能用这条路的场景，别依赖手动刷新。 三、目录刷新要克制 刷新接口里的目录刷新会一次清空整个路径下的所有缓存，节点随即集中回源。低峰期对个小目录影响有限；高峰期对图片目录来一次，回源洪峰可能把源站带宽打满，连带接口一起变慢。原则：只刷变更过的具体文件，目录刷新留给紧急情况，比如误发了错误版本需要立即撤回。刷新提交后几秒到几分钟才生效，别刷一次没见效就连刷几次，先确认提交的 URL 对不对。 四、源站响应头配合 刷新只解决 CDN 这一层，浏览器缓存由源站的 Cache-Control 决定。带 hash 的文件可以放开：Cache-Control: max-age=31536000, immutable；HTML 入口文件设 no-cache 或极短时间，保证引用更新的入口始终新鲜。注意改了 Cache-Control 之后，旧的头策略还留在已缓存的文件里，需要配合一次刷新才对新访问生效。两层缓存分开考虑，才不会出现"CDN 刷了、用户浏览器还抱着旧文件"的半截问题。