Service Worker 无法重定向404，但可在fetch阶段拦截图片请求并静默替换为预缓存占位图实现兜底；需在install时预缓存占位图，fetch中用request.destination==='image'识别、结合缓存匹配与超时控制返回占位图，注意CORS图片需用no-cors模式处理。
Service Worker 本身不能“重定向”404，但它可以在资源请求失败时主动返回一张预缓存的本地占位图，视觉上等效于兜底处理。关键不是等 404 发生再跳转，而是在 fetch 阶段拦截、判断、兜底——把失败请求“静默替换”为占位图响应。
预缓存占位图，确保它永远可用
在 Service Worker 安装阶段，必须提前把占位图（如 /placeholder.svg）存入缓存。它不能依赖网络加载，否则兜底链就断了：
- 推荐用 Workbox 的
precacheAndRoute，自动处理哈希校验和版本更新 - 手动方式：在
install事件中调用caches.open('static-v1').then(cache => cache.put('/placeholder.svg', response)) - 占位图建议放在
public/或根静态目录下，路径固定，不带动态参数
在 fetch 中识别图片请求并兜底
监听 fetch 事件，只对图片类请求做兜底，避免影响脚本、样式等关键资源：
- 用
request.destination === 'image'准确识别<img>请求（比后缀判断更可靠） - 先查缓存：
caches.match(request)，命中则直接返回 - 未命中则发网络请求，但加上超时控制：
Promise.race([fetch(request), timeout(5000)]) - 若 fetch 拒绝、超时或响应状态非 2xx，直接返回
caches.match('/placeholder.svg')
注意 CORS 图片的特殊处理
第三方图片（如 CDN 上的头像）常带 CORS 限制，此时无法读取响应状态码：
- fetch 时需加
mode: 'no-cors'，但响应变成 opaque，status 始终为 0 - 这种情况下，兜底逻辑更依赖缓存未命中 + 超时，而非状态码判断
- 建议对这类资源单独缓存一个轻量 SVG 占位图，避免 base64 大图拖慢 SW 启动
不推荐的误区
有些做法看似合理，实则无效或引发问题：
- 试图在 SW 里修改 DOM 中的
img.src—— SW 没有 document 对象，根本不可行 - 注册前用 HEAD 请求检查
/sw.js是否存在 —— 这解决的是注册报错，和资源兜底无关 - 把占位图路径写死在 HTML 里（如
<img src="/placeholder.svg">）却不配合 SW 替换 —— 失去真实图片加载机会
