txiki.js 中 Fetch API 的现代化改造之路

txiki.js 作为一个轻量级的 JavaScript 运行时，近期对其 Fetch API 实现进行了重要升级。本文将深入探讨这次改造的技术背景、实现方案以及未来规划。

原有实现的局限性

项目原本采用了第三方 fetch polyfill 实现，但随着项目发展，这一方案逐渐暴露出几个关键问题：

1. 流式处理缺失：现有实现不支持请求/响应的流式处理，这在现代 Web 开发中已成为重要需求
2. 运行时检测机制：polyfill 在导入时进行特性检测，这种静态检测方式与动态运行时环境不匹配
3. 维护性挑战：上游维护者对添加流式支持持保留态度，限制了功能演进

技术决策与实现方案

经过技术评估，团队决定将 fetch polyfill 直接内化(vendor)到项目中。这一决策基于以下考量：

• 代码体积适中，内化成本可控
• 便于深度定制，移除不必要的运行时检测
• 能够自主添加流式处理等现代特性

实现过程中，团队还考虑了更激进的方案——完全基于 libcurl 原生实现 Fetch API，类似 Node.js、Deno 和 Bun 的做法。这一思路的优势在于：

• 减少对 XHR 的依赖，简化技术栈
• 更直接的底层控制能力
• 与现代运行时生态保持一致

高级特性支持展望

在讨论中，社区提出了几个值得关注的进阶需求：

1. 全双工通信：支持 duplex: "half" 参数以实现请求/响应并行处理
2. HTTP/2 支持：利用 libcurl 已有能力提供更高效的传输协议
3. 扩展控制能力：如自定义证书验证、上传进度回调等浏览器不具备的特性

当前进展与未来方向

目前已完成基础 polyfill 的内化工作，下一步将重点放在：

• 原生流式处理支持
• 性能优化
• 特殊场景下的扩展能力

这次改造体现了 txiki.js 在保持轻量级特性的同时，对现代 Web 标准的坚定承诺。通过自主掌控核心 API 实现，项目获得了更大的技术灵活性和发展空间。