演示清单快速更新的效果。
进入本案例 www 目录。本案例已提供清单文件，只需创建前端脚本：
freecdn js --make开启 HTTP 服务：
不断刷新页面，可见程序并没有重新加载清单文件。难道清单不会自动更新？
事实上 freecdn 不会因为刷新页面而重新加载清单，而是每隔 300s 加载一次。这对于更新频繁的场合似乎有些落后。尽管可配置更短的间隔，但更高的检测频率会带来更多请求，消耗网站更多流量。
如果有个服务能在清单变化时通知前端，这样不仅无需频繁检测，还能第一时间更新，效率大幅提升。本案例我们讲解如何实现这样的效果。
安装 freecdn 更新推送服务：
npm install freecdn-update-svc -g启动服务：
freecdn-update-svc --timer 10该服务默认使用 30000 端口。出于演示，这里每隔 10s 检测一次清单文件（默认 60s）。
新建 配置文件：
@update
services=ws://127.0.0.1:30000合并配置到当前清单：
freecdn manifest --merge ../custom.conf新建隐身窗口：
前端通过 WebSocket 和更新服务保持连接；更新服务显示有新用户加入，并开始对源站点的清单文件进行定期检测。
我们修改 freecdn-manifest.txt 模拟清单更新，例如将 /logo.png 的配置修改成如下内容：
/logo.png
https://ajax.cdnjs.com/ajax/libs/browser-logos/62.0.11/chrome-canary/chrome-canary.png
https://cdnjs.cloudflare.com/ajax/libs/browser-logos/62.0.11/chrome-canary/chrome-canary.png
https://cdn.staticfile.org/browser-logos/62.0.11/chrome-canary/chrome-canary.png
https://lib.baomitu.com/browser-logos/62.0.11/chrome-canary/chrome-canary.png
https://cdnjs.loli.net/ajax/libs/browser-logos/62.0.11/chrome-canary/chrome-canary.png
hash=c0da/VG6RjQ0Ej6ltL9BtZExgHKBVMhgTvE7PUmOKMo=几秒钟后，更新服务检测到站点清单文件发生变化，通知所有在线用户。前端收到推送消息后，重新加载清单文件，得到最新的清单内容：
刷新页面，图片变成最新版本：
注意，freecdn 默认为所有资源设置了 30s 内存缓存，因此刷新后可能不会立即生效，需要稍等一会再刷新。（日志显示 memory cache 说明资源直接从内存缓存加载，过期后才会请求 ServiceWorker）
如果觉得单个更新服务不够稳定，你可以设置多个，使用空白字符分隔：
@update
services=url1 url2 ...如果觉得搭建更新服务有些麻烦，你可以使用本项目的公共服务：
@update
services=wss://freecdn1.etherdream.com:30000 wss://freecdn2.etherdream.com:30000该服务的协议非常简单，你可以 参考案例 自己实现一个更新服务。
如果你的站点不经常更新，那就没必要配置推送服务了，使用内置的轮询更新即可。
程序默认每隔 300s 检测清单文件是否有变化，你也可以调整轮询间隔：
@update
interval=100s掌握本文案例后，你可以在不改变业务逻辑的前提下，快速修改某个静态资源的内容，而不用 PURGE CDN 缓存、等待用户端缓存失效，非常适合紧急修复。
传统更改 URL 的方案，可能需要更新多个资源。例如为了修复有问题的图片文件，导致引用它的 CSS 文件也得修改（因为图片重新发布后 URL 变了），而引用了 CSS 文件的 JS 也得修改（因为 CSS 的 URL 也变了），引用了 JS 文件的 HTML 也得修改。。。一个文件的变化导致整个依赖链都得更新，浪费不必要的流量。