Service Worker 通过拦截请求并按网络状况切换预生成的多分辨率媒体资源实现流量节约，而非直接压缩文件；结合 navigator.connection API、分级缓存与策略响应，可智能代理分发适配版本。
Service Worker 本身不直接“动态限制”多媒体文件的原始大小，但它能通过拦截请求、重写响应或切换资源版本的方式，实现按需加载更小尺寸的媒体资源，从而有效节约用户流量。关键不在压缩文件本身，而在智能选择和代理分发。
基于网络状况切换媒体资源版本
利用 navigator.connection API 获取用户当前网络类型（如 slow-2g、4g）和有效带宽（downlink），Service Worker 可在 fetch 事件中动态替换请求 URL，指向预生成的低清版本：
- HTML 中仍引用标准路径，例如
<video src="/videos/intro.mp4"></video> - Service Worker 拦截该请求，检查
navigator.connection.downlink ，则改用 <code>/videos/intro-480p.mp4 - 需提前在服务端或构建流程中生成多分辨率版本，并确保路径可预测
拦截并注入自适应媒体策略
对支持 <source></source> 的 video/audio 元素，可结合 HTML 的 media 属性与 Service Worker 配合：
- 页面加载时，JS 根据网络条件设置
video.src或source.media，但易被绕过或延迟 - Service Worker 在 fetch 阶段统一接管：识别媒体请求后，返回一个轻量级的“策略响应”，例如重定向到 CDN 的自适应流地址（如 HLS 的 m3u8 清单），由播放器自动选清晰度
- 适用于视频网站，避免客户端重复判断逻辑
缓存分级 + 按需降级响应
不只做“转发代理”，还可主动构造响应：
- 首次请求高清资源时，Service Worker 缓存它；后续请求若检测到弱网，从缓存中读取并用 WebAssembly 模块（如 FFmpeg.wasm）实时转为低码率 blob，再
new Response(blob, { headers })返回 - 更实用的做法是预缓存多个版本（
intro-360p.webm、intro-720p.mp4），按条件匹配并返回对应缓存条目 - 注意：实时转码开销大，仅适合小文件或离线场景；生产环境推荐预生成 + 策略路由
配合 HTTP 缓存头减少重复加载
Service Worker 与传统缓存协同工作，避免重复下载同一资源的不同版本：
- 为高清资源设
Cache-Control: public, max-age=31536000, immutable，确保长期复用 - 为低清备用资源设
private, max-age=604800，允许用户端缓存但不被 CDN 共享 - 在 fetch 事件中，先查 cache，命中则直接返回；未命中再根据网络条件发起新请求并缓存结果
