如何用 puter.workers.create() 从 JS 文件部署 Worker 并通过覆盖源文件完成更新？-育师

如何用 puter.workers.create() 从 JS 文件部署 Worker 并通过覆盖源文件完成更新？

【免费下载链接】puter🌐 The Internet Computer! Free, Open-Source, and Self-Hostable.项目地址: https://gitcode.com/GitHub_Trending/pu/puter

你需要把一个包含 router 代码的 JavaScript 文件部署为 Puter 的 Serverless Worker，并且后续修改代码时保持同一个 Worker 名称和 URL 不变。这个任务分两步：先用puter.workers.create(workerName, filePath)从 Puter 账号里的 JS 文件创建并部署 Worker，之后每次更新都通过覆盖该 Worker 的源文件来完成，而不是重新创建一个新 Worker。

前提条件（来自 create 文档）：

需要一个已验证邮箱的 Puter 账号；
运行环境加载了 Puter.js（文档示例使用https://js.puter.com/v2/脚本标签）；
Worker 源码文件不能超过 10MB；
workerName只能包含字母、数字、连字符（-）和下划线（_）。

第一步：准备 Worker 源文件

Worker 代码必须是一个包含 router 代码的 JS 文件，且该文件要先存在于你的 Puter 账号的文件系统中。文档示例用puter.fs.write()直接把代码写入my-worker.js：

const workerCode = ` // A router for /api/hello router.get('/api/hello', async (event) => { return 'Hello from worker!'; }); `; // 保存 worker 代码到 Puter 账号中的 my-worker.js await puter.fs.write('my-worker.js', workerCode);

puter.fs.write()的overwrite选项默认为true（见 write 文档），因此对已存在的文件调用它会直接覆盖内容，这正是后面更新 Worker 依赖的行为。

第二步：调用 create() 部署 Worker

puter.workers.create()有三种调用形式：

puter.workers.create(workerName, filePath) puter.workers.create(workerName, filePath, appName) puter.workers.create(workerName, filePath, options)

参数说明：

workerName（必填）：Worker 的名称，决定其 URL。
filePath（必填）：Puter 账号中包含 router 代码的 JS 文件路径。
appName（可选）：绑定到你账号中一个已存在的 app，Worker 就以该 app 身份运行，不会创建沙箱 app。注意：如果你的代码本身就是作为 Puter app 运行的，只能命名你创建的 app，否则会被403拒绝；从 GUI 或使用 user token 部署时可以命名账号内任意 app。
options（可选）：{ sandbox: boolean }，控制是否给 Worker 一个独立的沙箱 app。默认值取决于认证方式——以 app 身份部署时默认false（Worker 作为你的 app 运行）；以 user token（GUI、root access token）部署时默认true，此时会自动创建或复用sandbox-<workerName>app。

返回值是一个Promise，成功时解析为 WorkerDeployment 对象，包含success（是否成功）、url（部署后的 URL）和errors（部署过程中的错误数组）；失败时抛出带原因的Error：

// 从 Puter 账号中的文件创建并部署 worker const deployment = await puter.workers.create('my-api', 'my-worker.js'); console.log(`Worker deployed at: ${deployment.url}`);

第三步：验证部署结果

文档明确说明：Worker 创建或更新后，完全生效（传播到所有边缘服务器）可能需要 5 到 30 秒。文档示例的做法是等待 5 秒后请求 Worker 的端点：

setTimeout(async () => { const response = await fetch(`${deployment.url}/api/hello`); puter.print('→ Test response: ', await response.text()); }, 5000);

上面的示例中，请求/api/hello后打印响应文本；对应文档里 router 代码返回的字符串是Hello from worker!（文档示例输出）。如果你请求后长时间拿不到响应，先考虑文档给出的 5～30 秒传播窗口，而不是立刻判定部署失败。

第四步：通过覆盖源文件更新 Worker

这是本文的关键约束：Worker 一旦创建，名称和 URL 在整个生命周期内保持不变。部署变更时不要再用新名字调用一次create()——那样旧 Worker 仍在其旧 URL 上运行，而你的调用方会指向一个被孤立的新实例。正确的更新路径是覆盖它的源文件：

用puter.workers.get(workerName)查询 Worker 信息。它返回 WorkerInfo 对象，字段包括name、url、file_path（Worker 源码文件路径）、file_uid、app_uid、created_at；如果 Worker 不存在则返回undefined。
用puter.fs.write()把新代码写回file_path。Worker 会从该文件重新部署，名称和 URL 不变，已经在调用它的代码无需任何修改。

// 查询已部署 worker 的源文件路径 const info = await puter.workers.get('my-api'); // 用新代码覆盖它 —— Worker 会在同一名称和同一 URL 上重新部署 await puter.fs.write(info.file_path, updatedWorkerCode);

文档中的说明是：覆盖后https://my-api.puter.work会继续对外提供服务，但运行的已是你的更新代码，现有调用方保持工作。更新后的传播时间同样受 5～30 秒的窗口影响。

限制与注意事项

不要重名重建：重新以不同名字create()不会更新原 Worker，只会产生一个孤立的新部署。
绑定变更不迁移数据：Worker 以某个 app 身份运行，这个身份决定了它能访问的puter.kv命名空间和AppData目录。如果重新部署时改了sandbox设置或appName，Worker 会指向另一个命名空间，旧身份下写入的数据留在原地。
无沙箱的 Worker 共享状态：一个 app 部署多个 Worker 且不带sandbox: true时，它们都以该 app 身份运行，共享同一 KV 命名空间和 AppData 目录，一个 Worker 写入的 key 其他 Worker 可读可覆盖。需要相互隔离时，用sandbox: true或为每个 Worker 绑定独立的appName。
体积限制：Worker 不能大于 10MB。