Wrangler：Cloudflare 给 Rust + WASM 开发者造的那把锤子

背景

要理解 wrangler 是什么、解决了什么问题，需要先把它涉及的三层技术说清楚。

Cloudflare Workers是 Cloudflare 的边缘计算平台。和传统的云函数不同，Workers 不是跑在某个固定的数据中心，而是分布在 Cloudflare 全球 300 多个节点上，每次请求会被路由到距离用户最近的节点执行。

Workers 的运行时不是 Docker 容器，也不是虚拟机，而是 V8 isolate——Chrome 和 Node.js 背后的同一个 JavaScript 引擎。每个请求在独立的 isolate 里执行，启动时间在微秒级，远低于容器的冷启动延迟。这套架构让 Workers 在延迟和资源利用率上都有明显优势。

但最初的 Workers 只支持 JavaScript。

原文地址：https://blog.cloudflare.com/introducing-wrangler-cli/

JavaScript 的边界在哪里

JavaScript 在写业务逻辑、处理请求、调用 API 这类场景下表现很好。Node.js 的出现让 JavaScript 从浏览器延伸到了服务器，这是一次重要的扩展。

但 JavaScript 有一个固有的局限：它不适合做计算密集型任务。

游戏引擎、图像处理、音视频编解码、密码学运算、科学计算——这些场景对性能的要求是 JavaScript 无法满足的。不是语言设计不好，而是动态类型、GC、JIT 编译这些特性在带来开发效率的同时，也带来了性能上的不确定性和上限。

WebAssembly（WASM）在 2017 年以一种务实的方式解决了这个问题。它不是要取代 JavaScript，而是在 Web 平台上为高性能代码提供一个专属的运行环境。

WASM 是一种二进制格式的指令集，可以在现代浏览器和 V8 等运行时中以接近原生的速度执行。关键一点是：C、C++、Rust 这些语言都可以编译成 WASM。这意味着大量原本只能在本地运行的高性能库，现在有机会在 Web 平台上运行。

V8 同时支持 JavaScript 和 WebAssembly。这也意味着 Cloudflare Workers 从一开始就有支持 WASM 的基础，要做的只是把这条路铺好。

Rust 为什么成为首选

WASM 的工具链有几条路：

• Emscripten：面向 C 和 C++，是最早成熟的 WASM 工具链，历史悠久，但配置相对复杂
• AssemblyScript：面向 TypeScript 开发者，语法接近 TypeScript，学习曲线低
• Rust + wasm-pack：Rust 的 WebAssembly 工作组在 2018 年投入了大量精力，把 Rust 到 WASM 的整个工具链打磨得非常完整

Cloudflare 选择先从 Rust 开始，原因是工具链在当时已经足够成熟，而 Rust 本身在性能、内存安全、跨平台这几个维度上也完全契合 Workers 场景的需求。

Emscripten 和 AssemblyScript 的支持计划在后续跟进，Rust 只是起点。

工具链完整不等于开发者能用

这里有一个容易被忽略的问题：技术可行，不等于开发者能顺畅地用上它。

在 wrangler 出现之前，如果你想在 Workers 上跑一个 Rust 写的 WASM 模块，需要经历这些步骤：

1. 用wasm-pack build编译 Rust 代码，生成.wasm文件和 JS 胶水代码
2. 手动改造 JS 胶水代码，因为wasm-pack生成的是面向浏览器的 ES module 格式，Workers 的 WASM 实例化方式不同，需要手动删掉 import 语句、重新组织 importObject、调整模块结构
3. 写 Worker 脚本来调用 WASM 函数
4. 通过 Cloudflare API 手动上传.wasm文件和 Worker 脚本

这个流程对于深度了解 WASM 工作原理的人来说是可操作的，但对于刚接触这套技术栈的开发者来说，光是胶水代码的改造就可能让人卡住很久。

Cloudflare 在之前的博客里也记录了这个手工流程，并且明确提到这是一个繁琐且容易出错的过程。

wrangler 要解决的就是这个问题：把上面这些手动步骤全部封装进去，让开发者可以专注在代码本身。

wrangler 做了什么

wrangler 是一个用 Rust 写的命令行工具，提供三个核心动作：

build：调用wasm-pack，编译 Rust 代码为 WASM，同时自动处理 JS 胶水代码的适配，生成可以直接在 Workers 上运行的产物。

preview：把构建产物发送到 Cloudflare 的预览服务，在真实的 Workers 运行时环境里测试代码行为，不需要先正式发布。

publish：将 WASM 文件和 Worker 脚本一起上传到 Cloudflare，完成部署。

安装方式直接用 cargo：

cargoinstallwrangler

整个工作流从这里开始：

# 编译 Rust 到 WASMwrangler build# 在预览环境测试wrangler preview# 发布到全球边缘节点wrangler publish

三条命令，覆盖了从本地开发到线上部署的完整路径。

现阶段还缺什么

博客里对此有很诚实的说明：wrangler 在发布时是一个"够用但不完整"的工具。

明确缺少的能力包括：

• 代码检查（lint）：识别潜在问题和不规范写法
• 测试框架集成：在本地跑单元测试
• 性能基准测试（benchmark）：量化代码性能
• 体积分析（size profiling）：WASM 产物的体积直接影响冷启动时间，是一个重要指标

这些功能都在计划里，但 Cloudflare 选择先把能用的部分发出来，而不是等到"完整"之后再发布。

为什么要在这么早的阶段开源

这个决策背后有一个明确的工程哲学。

新技术在内部打磨得再久，都不如放到真实开发者手里迭代快。开发者在使用过程中遇到的障碍、提的 issue、反馈的 workflow 诉求，是产品设计阶段预料不到的。

缩短从产品到用户的反馈循环，比追求初始版本的完整度更重要。

wrangler 在这个阶段开源，目的是邀请更多开发者进来：提 issue、构建项目模板、写使用体验、参与讨论。工具的形态应该由用它的人来塑造，而不只是由设计它的人来决定。

小结

wrangler 是一个工具，它本身的代码量不大，逻辑也不复杂。但它背后代表的是一条完整的技术路径：

Rust 源码 → wasm-pack 编译 → WASM 二进制 + 胶水代码（wrangler 自动处理适配） → Cloudflare Workers 预览 / 发布 → 跑在全球 300+ 边缘节点

更重要的是它背后的判断：当一项技术本身已经可用，但开发者仍然无法顺畅使用时，工具链的缺失才是真正的障碍。wrangler 做的事，是把这条路上的石头搬开。

对于关注边缘计算、WebAssembly 或者 Rust 生态的人来说，这个方向值得持续关注。五年之后的今天，Cloudflare Workers 已经成为边缘计算领域最成熟的平台之一，wrangler 也早已进化为功能完整的开发工具，支持了当初 TODO 列表里所有缺失的能力。