如何用 Service Worker 实现静态资源的“占位图”兜底逻辑

如何用 Service Worker 实现静态资源的“占位图”兜底逻辑

网络状态总有掉链子的时候，图片加载失败导致页面出现一片空白或扎眼的破碎图标，体验实在不佳。好在 Service Worker 提供了一套巧妙的拦截机制，能在资源加载失败时，自动替换成一张预置的占位图，比如一个灰色方块或加载动画，让页面保持体面。这套逻辑的核心，就在于精准拦截请求、判断资源类型，并在关键时刻执行“回退”操作。

预缓存占位图资源

任何兜底策略的前提，是兜底资源本身必须绝对可靠。因此，第一步就是在 Service Worker 的安装阶段，将占位图（例如 /placeholder.svg 或 /fallback.jpg）提前塞进缓存，确保它随时待命。

• 如果项目使用了 Workbox，那么workbox-precaching 模块会是首选，它能自动处理资源哈希和版本更新，非常省心。
• 手动方案则需要调用 caches.open().put() 来缓存一个 Response 对象。这里有个细节要注意：Response 的 body 通常只能读取一次，稳妥的做法是用 Response.clone() 做个备份再存。
• 建议把占位图放在项目的静态目录下，路径固定，避免任何动态生成的不确定性。

拦截图片请求并实现兜底逻辑

重头戏在 fetch 事件里。首先需要识别出图片请求（可以通过 URL 后缀判断，或者更精准地检查 request.destination === ‘image’），然后按顺序尝试获取资源，任何一步失败，就亮出我们的“底牌”。

• 缓存优先：先用 caches.match() 查查缓存里有没有这张图，有的话直接返回，速度最快。
• 网络请求与超时控制：缓存没命中，就发起网络请求。为了防止糟糕的网络一直挂起请求，可以用 Promise.race([fetch(), timeoutPromise]) 设置一个超时竞争。
• 触发兜底：一旦 fetch 被拒绝、超时，或者返回的状态码不是2xx成功系列，就跳过复杂的错误处理，直接执行 return caches.match(‘/placeholder.svg’)。
• 对了，处理跨域图片（CORS）时，fetch 可能需要加 { mode: ‘no-cors’ }，但这会让我们无法读取响应状态码。这种情况下，兜底就更依赖缓存命中或超时机制了。

区分不同兜底场景（可选增强）

更极致的体验，是为不同场景提供更合适的 fallback。这虽然可选，但能显著提升细节质感。

• 针对普通的 标签请求（destination === ‘image’），返回一个轻量的小尺寸 SVG 占位图最为合适，体积小且缩放不失真。
• 对于 CSS 中引用的 background-image 请求（其 destination 通常是 ‘subresource’），可以考虑返回一个带透明背景的 base64 图片，这样可以避免背景突然“坍缩”导致的布局跳动。
• 如果是首屏关键图片，还可以采用更主动的策略：在 HTML 里直接内联或写入 src=“/placeholder.svg”，然后由 Service Worker 在后续拦截中，尝试替换为真实地址。这通常需要配合自定义的 HTTP 头或 URL 查询参数来标识。

避免缓存污染与调试技巧

兜底逻辑虽好，但不能让它掩盖了真实存在的问题。上线后必须做好隔离和监控，否则可能会“好心办坏事”。

• 精准拦截：作用范围务必限定在明确的图片资源上，千万不要误伤了 Ja vaScript、CSS 或 API 接口，否则会引发难以排查的诡异问题。
• 有效调试：在 Chrome DevTools 的 Application 面板下，找到 Service Workers 并勾选 “Update on reload”。同时，在 Network 面板禁用缓存，这样可以确保每次都能测试到最新的网络获取逻辑。
• 添加日志：在 fetch 事件的处理函数中加入 console.debug() 语句，记录下哪些 URL 被兜底了以及原因是什么。当然，生产环境记得移除这些日志。
• 埋点感知：可以在兜底返回的 Response 中，添加一个自定义 Header（比如 X-Fallback: true）。这样前端 Ja vaScript 就能感知到这次命中兜底，便于进行数据埋点或向用户做出适当提示。

最后提一个看似简单却极易踩坑的点：用来兜底的占位图本身，必须是预先缓存好的。绝对不能在 fetch 事件里发现原图加载失败后，才去动态请求这张占位图——万一那时候网络彻底断了，整个兜底链路就会跟着一起失败，策略也就完全失效了。