Evidence项目中使用自定义DuckDB-WASM扩展仓库的解决方案

在企业级应用开发中，我们经常会遇到生产环境网络受限的情况。本文针对Evidence项目中无法从默认地址加载DuckDB-WASM扩展的问题，提供了一套完整的解决方案。

问题背景

Evidence项目默认会从DuckDB官方扩展仓库加载WASM扩展。但在某些严格管控的企业网络环境中：

1. 生产服务器可能无法访问外部网络
2. 安全策略可能禁止访问特定域名
3. 网络延迟可能导致扩展加载失败

技术原理

DuckDB-WASM的扩展加载机制是通过Service Worker拦截网络请求实现的。核心思路是通过修改Service Worker脚本，将原本指向官方仓库的请求重定向到内部镜像地址。

解决方案实施步骤

1. 构建项目

首先完成Evidence项目的标准构建流程：

npm install
npm run sources
npm run build

2. 定位Service Worker文件

构建完成后，在dist目录下可以找到名为fix-tprotocol-service-worker.js的文件，这是控制扩展加载的关键脚本。

3. 修改Service Worker

在Service Worker的fetch事件处理器中添加重定向逻辑：

self.addEventListener('fetch', (event) => {
  const requestURL = event.request.url;
  const officialExtensionsURL = "https://extensions.duckdb.org";
  
  if (requestURL.startsWith(officialExtensionsURL)) {
    const internalURL = requestURL.replace(
      officialExtensionsURL, 
      "http://your-internal-mirror"
    );
    event.respondWith(fetch(internalURL));
    return;
  }
  
  // 原有逻辑保持不变
});

4. 部署内部镜像

需要在内网搭建一个包含以下内容的镜像服务：

• 保持与官方仓库相同的目录结构
• 包含项目所需的全部扩展文件(.wasm和.json)
• 确保MIME类型配置正确

进阶建议

1. 版本控制：建议内部镜像与官方仓库保持版本同步，定期更新
2. 缓存策略：可以适当延长Service Worker的缓存时间，减少网络请求
3. 安全加固：如果使用HTTPS，确保内部镜像也配置了有效证书
4. 监控机制：添加扩展加载失败的回退机制和日志记录

注意事项

1. 此方案属于临时解决方案，建议在官方支持自定义仓库配置后迁移
2. 修改构建产物可能影响后续升级，建议将修改脚本化
3. 不同Evidence版本可能Service Worker实现有差异，需要测试验证

通过这套方案，企业可以在严格管控的网络环境下，依然保持Evidence项目的完整功能，同时满足安全合规要求。