最近团队接了几个工业SaaS平台的数据采集需求，清一色都是PWA架构。一开始用常规的HTTP请求框架去做，要么拿到的是几天前的旧数据，要么页面骨架出来了但核心数据区域全是空的，抓下来的HTML全是缓存壳子。一开始以为是对方做了强反爬，调了代理、浏览器指纹都没用，最后抓包逐层排查才发现，问题全出在Service Worker的缓存机制上。
这两年PWA在企业级系统、工业监控平台里用得越来越多，离线可用、秒开、接近原生的体验，对用户很友好，但对数据采集来说就是实打实的坑。常规的采集思路碰到PWA基本失灵，要么拿不到数据，要么拿到的全是过期缓存。
本文就从采集视角拆解Service Worker的缓存机制，分享四层不同的提取方案，以及生产环境踩过的所有坑，帮你搞定绝大多数PWA站点的数据采集。
一、先搞懂：Service Worker为什么是PWA采集的“拦路虎”
很多人对Service Worker的理解停留在“离线缓存”，但从采集视角看，它本质是一个安装在浏览器里的网络代理层。所有页面发出的HTTP请求，都会先经过SW的fetch事件，由SW决定是返回缓存、发请求到服务器，还是两者并行处理。
和浏览器自带的HTTP缓存不一样，SW的缓存是完全可编程的，存储在独立的Cache Storage里，不受HTTP缓存头的控制。这就是为什么你加了Cache-Control: no-cache也没用——你管的是浏览器缓存，管不了SW自己的缓存。
1.1 从采集视角看SW的缓存生命周期
SW的缓存分为三个核心阶段，对采集影响最大的是更新
