文章标题载入中
一次手机端 Logo 裂图的偶发故障，牵扯出 W3C Fetch 规范对 no-cors 模式下 cache:no-store 的严格禁令，以及底层 HTTP 代理对已压缩二进制图片强行 Gzip 的解码失效。本文复盘如何在不引入任何重型构建工具的前提下，用最纯净的原生 Web 标准构建坚韧的容灾防线。
在现代前端工程中，图片加载失败通常被归咎于网络超时或 404 路径错误。但在纯原生零构建的架构下，有时一个看似微不足道的一像素裂图，背后却往往隐藏着浏览器底层规范与代理压缩策略的深层博弈。
今天下午在真机实测纸境工坊时，遇到了一个极其诡异的现象：桌面端 Chromium 浏览器一切正常，但在 iOS Safari 与部分移动端浏览器上，顶部的 Logo 头像却始终显示为破损图标。检查服务器文件，logo.png 真实存在且体积完整；直接通过 curl 访问也返回 HTTP 200，路径与权限毫无瑕疵。
通过远程真机调试与注入式日志捕获，真正的元凶终于浮出水面：在之前用于清理陈旧缓存的轻量 Service Worker 脚本中，写着一行看似人畜无害的穿透监听器：event.respondWith(fetch(event.request, { cache: 'no-store' }))。然而，根据 W3C Fetch 官方规范，HTML 中的普通 img 标签发起的是 mode: 'no-cors' 请求，WebKit 引擎对规范执行极其严苛——如果请求处于 no-cors 模式且显式传入了非默认的 cache 参数，浏览器会直接抛出 TypeError 异常！这个未捕获的 Promise 错误导致整个拦截链路崩溃，图片瞬间被判定为加载失败。
雪上加霜的是后端的压缩策略。Node.js 的原生分发逻辑中，仅根据请求头是否包含 Accept-Encoding: gzip 且体积大于 384 字节，就对所有响应统统进行了 zlib 压缩。然而 PNG 图片本身已经采用了 DEFLATE 算法压缩，强行二次 Gzip 不仅会导致体积反向膨胀，还会给某些移动端解码器带来额外的解压校验阻碍。
解决之道依然秉持奥卡姆剃刀原则：首先彻底拔除 Service Worker 中多余的 fetch 拦截监听，让静态资源回归浏览器原生网络栈；其次在服务端建立严格的 isCompressible 白名单判定，仅对 HTML、CSS、JS、JSON、SVG 启用 Gzip；最后在前端 img 标签上增加 onerror 兜底注入。做底层原生开发就是这样，它剥离了框架包装的幻觉，逼着我们直面协议本身的每一个字节。