Service Worker：离线缓存的核心
Service Worker绝对是PWA的灵魂。它就像个躲在浏览器背后的脚本，能拦截网络请求，让我们完全控制缓存策略。
注册Service Worker很简单：
关键在sw.js这个文件里。我们通常在install阶段缓存静态资源：
而fetch事件的处理才是精髓所在。我比较喜欢"网络优先，失败再用缓存"的策略：
如果是那种实时性要求不高的API接口，也可以反过来用"缓存优先"的策略，这个得根据具体业务场景来定。
Web App Manifest：定义应用外观
manifest.json这个文件决定了用户"安装"后看到的样子：
这里有个小坑：icons一定要准备多个尺寸，从192x192到512x512都得有，不然不同设备上图标可能会糊掉。记得在HTML里用link标签引入：
实际开发中遇到的坑
说起来都是泪，第一次做的时候忘了配置HTTPS，Service Worker死活注册不上。后来才知道这货必须在安全环境下才能运行。本地开发可以用localhost，但上线必须配SSL证书。
还有个兼容性问题，iOS上的Safari对PWA的支持一直比较保守，比如beforeinstallprompt事件就不支持。这时候只能通过引导用户手动点击分享菜单里的"添加到主屏幕"来解决。
缓存更新也是个技术活。我现在的做法是每次发布新版本就更新CACHE_NAME，然后在新Service Worker的activate事件里把旧的缓存全清掉：
效果和收益
加上PWA特性后，最直观的感觉就是页面二次打开速度飞起，因为静态资源都从缓存走了。我们的某个活动页经过PWA改造后，跳出率直接降了15%，用户停留时间也明显变长了。
如果配合Lighthouse跑个分，在"Progressive Web App"这一项基本上能冲到90分以上。现在各大应用市场审核越来越严，用PWA技术做个轻量级的应用版本，也是个不错的备选方案。
总结
PWA不是什么高深莫测的黑科技，本质上就是Service Worker + Web App Manifest的组合拳。花个两三天时间把这两块搞明白，就能让网页的体验提升一个档次。特别是在网络条件不稳定的场景下，离线功能真的能救命。现在回头看看，当初折腾Service Worker的那些时间，花得挺值的。