在 Cloudflare Worker 中混淆 JavaScript

“在 Worker 中运行 AfterPack”有三种含义，而且它们不能互相替代。AfterPack 如今就能在你的 Worker 中运行，是一个从 npm 安装的 WebAssembly 模块。Pro 运行在 AfterPack 的云端，从 Worker 访问它与从其他任何地方访问并无二致。在 Workers for Platforms 上运行的 AfterPack——一个由 AfterPack 运营、运行在 Workers for Platforms 账户内、按请求提供新形态的 Pro——已列入路线图，目前尚不存在。

本页按上述顺序介绍这三种情况。

AfterPack，在你自己的 Worker 中

@afterpack/wasm 是编译成 WebAssembly 的 AfterPack。它与 CLI 和框架插件运行的是同一个 Rust 引擎，只是面向 wasm32 构建，而不是面向你机器的架构。

npm install @afterpack/wasm

import { obfuscate } from "@afterpack/wasm";

export default {
  async fetch(request) {
    const source = await request.text();
    const result = await obfuscate({ path: "app.js", source }, { preset: "hard" });
    return new Response(result.bytes, {
      headers: { "content-type": "application/javascript" },
    });
  },
};

集成就是这么多。不需要 init 调用，不需要 nodejs_compat 标志，也不需要为 .wasm 文件编写 wrangler 规则。该模块没有任何 WebAssembly 导入，因此会在你第一次调用 obfuscate 时同步实例化，而包的 exports 映射会自动为你的打包工具提供适用于 Worker 的入口。同样的导入在 Node 中也能用，那里会由另一个入口从磁盘读取二进制文件。

其接口与 @afterpack/core 完全相同——obfuscate、obfuscateAll、version，全部是异步的，遇到无法发布的构建都会抛出异常。配置是配置页面中记录的同一个对象，包括 preset 和 seed。

除非无法使用，否则请用 `@afterpack/core`

@afterpack/core 附带原生二进制文件，速度更快。当宿主无法加载原生二进制时再选用 @afterpack/wasm：Worker、沙箱化的 CI 镜像、边缘函数。

它的代价

引擎二进制文件已经编译好，随包附带。

	体积
原始 `.wasm`	4.36 MiB
gzip 压缩后	1.25 MiB

Cloudflare 对 Worker 的体积限制是免费套餐压缩后 3 MB、付费套餐 10 MB，因此引擎在两者中都放得下。免费套餐放不下的是工作量：它把每次调用的 CPU 限制在 10 ms，而在笔记本电脑的一个核心上混淆一个 185 KB 的 bundle，在默认的 light 预设下需要不到 0.3 秒，在 medium 下约需 1 秒。超出演示范围的用途都需要 Workers Paid。

在每个请求上都混淆同一份资源的 Worker，每次都要付出这份 CPU 开销。如果你并不需要每个请求都换一种新形态，就在一个轮换周期内缓存结果，或者在构建中完成这项工作并提供其输出，以便控制费用。

你托管的包能做什么、不能做什么

你安装的 .wasm 执行的是 Free 保护。Pro 变换只在 AfterPack 的基础设施上运行，因此这个包里没有任何可以解锁的东西：没有可以绕过的密钥检查，也没有能把托管副本变成 Pro 构建的开关。key 的作用是把工作路由到云端；它不会在本地启用任何东西。

发布的包带有 npm provenance 记录——包版本、构建它的工作流，以及产物摘要——因此你可以把自己安装的字节与产生它们的那次构建对应起来。

Pro，现在：云端 API

Pro 不属于这个包，将来也不会属于。它只在 AfterPack 自己的基础设施上运行；这正是上文层级边界的意义所在。这个包带有的是它的客户端。

从 Worker 访问它，就是你已经在写的那个调用：给 @afterpack/wasm 传入 key，同一个 obfuscate() 就会以 Pro 运行。包在底层向 POST /v1/obfuscate/batch 发起 Pro 请求，因此 Worker 永远不需要手写 API 调用。云端 API 参考是完整的线路契约，部署模式解释了引擎换了运行位置之后会有什么变化。

有两个后果值得明确说明。你的源代码会离开你的 Worker，在 AfterPack 的云端处理——在内存中处理，不会持久化，详见隐私与数据处理。另外，如果无法连接云端，构建会失败即中止。

Pro 永远不会以由你托管的 wasm 形式发布

声称能在你自己的基础设施上运行 Pro 变换的包不是我们的。在安装任何使用这个名字的东西之前，请检查 npm provenance 记录。

路线图中：在 Workers for Platforms 上运行 AfterPack

尚不存在的形态：一个由 AfterPack 提供的 Workers 封装，运行在 Workers for Platforms 的 dispatch namespace 中，按请求提供新的形态。没有需要安装的包，也没有 Worker 到 Worker 的请求——Pro 构建在边缘执行，无需往返 Cloudflare 网络之外。

它在路线图上，但没有日期。本页的任何内容都不依赖于它，如今实际提供的内容见部署模式。对于“源代码绝不能离开我们的基础设施”这一要求，答案是免费的本地构建，如今即可使用。

如何选择

你想要	使用
在 Worker 中混淆，任何东西都不离开你的账户	`@afterpack/wasm`，即本页
在普通的 Node 构建中混淆	`@afterpack/core` 或 CLI
Pro 加固和按区域的指令	带上 `key` 的同一个调用，它会访问云端 API
在边缘、以 AfterPack 提供的封装运行 Pro	不可用

下一步

部署模式：本地与云端的区别，以及各自会存储什么。
云端 API 参考：Worker 为 Pro 构建调用的契约。
配置：两个包都接受的每一个键。
层级：Free 包含什么，Pro 又增加了什么。
隐私与数据处理：每种模式下有什么会离开你的机器。