三、与其它开源方案的对比（优缺点）
说明：同类需求在社区往往被拆成 「只服务于 Webpack」「只服务于把依赖换 CDN」「只在 SW 层统一拦请求」。本仓库选择 插件 + 小运行时，与下列路线各有所长。
3.1 对比 webpack-retry-chunk-load-plugin 一类
| webpack-retry-chunk-load-plugin（典型） | resource-fallback（本仓库） | |
|---|---|---|
| 优点 | 聚焦 Webpack async chunk；社区久、切入点清晰。 | Webpack 之外还提供 Vite；并统一 熔断、多前缀 URLs、Kill switch、DOM CSS chunk 等。 |
| 缺点（相对本库目标） | 不天然覆盖 Vite、纯 <script>/<link> 安全网、SystemJS legacy 与同构 resolver 语义。 | 维护与适配面更广；需在 Webpack 与 Observer 之间避免双处理。 |
3.2 对比 vite-plugin-cdn-import、vite-plugin-cdn2 一类
| 典型 CDN-import 插件 | resource-fallback（本仓库） | |
|---|---|---|
| 优点 | 把 React/Vue 等依赖 指到 CDN，减包体、加速构建。 | 面向 自家构建出来的 assets 在 运行时失败 时的 重试与多源回退（含回源），与「构建时把依赖换 URL」正交。 |
| 缺点（相对本库目标） | 多为 静态 URL 策略，对 主 CDN 挂掉后按规则链切换 不是同一问题域。 | 不替代「把业务依赖外置到 CDN」；若仅要外置依赖，应用专用 CDN 插件更简单。 |
3.3 对比 webpack-fallback-directory-resolver-plugin 一类
| Resolver 级「目录回退」 | resource-fallback（本仓库） | |
|---|---|---|
| 优点 | 在 模块解析 阶段解决「找不到文件」类问题。 | 解决 已在浏览器里发起的 URL 加载失败（网络/CDN/跨域等），与 构建期 resolve 层问题不同。 |
| 缺点（相对运行时回退） | 无法等价替代「线上 chunk URL 失效后的重试换源」。 | 构建期不参与「找不到源码」的回退逻辑。 |
3.4 对比基于 Service Worker（如结合 Workbox 自写路由）的路线
| Service Worker 拦截 fetch | resource-fallback（本仓库） | |
|---|---|---|
| 优点 | 可对 更广泛资源类型 做策略（字体、图片、子资源 fetch）；控制面极大。 | 无 SW 注册/更新/兼容性负担；与 Webpack/Vite 插件对齐，上手路径接近常规 SPA deploy。 |
| 缺点 | 生命周期、HTTPS、同源策略、fetch 与 <script> 失败关系需仔细建模；运维与排障更重。 | 不拦截任意 fetch；覆盖面以 脚本/样式加载与构建链能触达的路径为主（README TODO 里也承认图片等缺口）。 |
3.5 对比纯运维（换 publicPath、DNS、多云调度）
| 运维侧切换 | resource-fallback（本仓库） | |
|---|---|---|
| 优点 | 全站一致、对用户「无补丁」体感。 | 单次页面生命周期内对已下发 HTML/asset URL 仍可 多级重试换源，不依赖立刻发版。 |
| 缺点 | 已缓存的入口页仍可能指向坏域；Regional 抖动时体验粗。 | 在客户端多跑逻辑；需在团队内接受运行时脚本与语义边界。 |
小结：本工程的长处在于 多端构建适配 + 统一运行时状态机 + 与浏览器/webpack/vite 特例对齐；短处是 非 SW，对 任意网络请求不具备天然全集能力，Vite dev 动态 import 等也存在刻意未覆盖的范围。