WebBundle虽被寄予厚望，但当前仍处于实验阶段，Chrome对其离线分发大型Web应用的支持极为有限：需手动拖入或file://加载、强制启用flag、缺乏Service Worker拦截能力、不支持动态导入和跨源解析，甚至URL微小偏差都会导致资源失效——所谓“完整离线分发”在现实中并不存在；与其强行用尚未成熟的WebBundle“拧螺丝”，不如采用zip解压+file://、Electron/Tauri封装或Workbox预缓存等成熟方案，真正实现稳定、可调试、可更新的离线部署。

WebBundle 目前无法用于离线分发大型 Web 应用——它仍处于实验阶段，Chrome 仅支持加载本地 .wbn 文件（需启用 flag），且不支持 Service Worker 拦截后注入、动态 import() 加载、或跨 origin 资源解析。所谓“完整分发”在当前实现中并不存在。

Chrome 中加载本地 WebBundle 的实际限制

Chrome 117+ 支持通过 response = await fetch(new Request('app.wbn')) 加载本地 bundle，但前提是：

• app.wbn 必须由开发者手动拖入浏览器窗口（或通过 file:// 协议打开），不能通过 fetch() 从页面脚本发起跨 origin 请求
• 必须启用 --enable-features=WebBundles 启动参数，且禁用 site-per-process
• bundle 内所有资源的 URL 必须与声明的 source_map 完全匹配；哪怕路径末尾多一个 /，Response.url 就会变成 about:blank，导致 CSS/JS 无法正确解析上下文
• 不支持 importScripts() 或 Worker 构造函数加载 bundle 内脚本

Service Worker 无法拦截并返回 WebBundle 响应

你不能在 fetch 事件中 return new Response(bundleResponse.body, { headers: bundleResponse.headers }) 来“模拟”资源返回——因为：

• Response.body 是 ReadableStream，而 WebBundle 解析器只接受完整 ArrayBuffer 或 Blob 输入
• Chrome 的 WebBundleParser API（new WebBundleParser()）是内部接口，未暴露给页面脚本
• 即使你用 await response.arrayBuffer() 读取完 bundle，也无法在 SW 中调用解析逻辑；目前唯一可用的解析入口是 fetch('app.wbn') 自身，且它不接受 Response 实例作为输入

替代方案：用传统方式达成类似效果

如果目标是离线部署大型应用（如 Electron 替代、内网交付、PWA 离线包），更可行的路径是：

• 用 zip 打包全部静态资源 + 一个轻量 index.html，解压后用 file:// 打开（注意：现代 Chrome 默认禁用 file:// 下的 fetch，需加 --allow-file-access-from-files）
• 用 Electron 或 Tauri 封装，通过 main.js 注入 protocol.handle('app', ...) 提供虚拟 HTTP 服务
• 构建时生成完整 manifest.json + precacheManifest，配合 workbox-webpack-plugin 预缓存所有 chunk 和 asset，再用 npx serve -s build 启动本地 server —— 这才是当前最稳定、可调试、可更新的离线方案

WebBundle 的设计初衷是解决 HTTP/3 的服务器推送和跨站子资源复用，不是替代打包工具或离线分发机制。现在强行用它做离线包，等于拿锤子拧螺丝——不是不行，是每颗螺丝都要先打磨锤头。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《WebBundle：离线大型应用分发新方案》文章吧，也可关注golang学习网公众号了解相关技术文章。