我与 Workers 的爱恨情仇

从第一个 hello world 到博客上线，中间踩的坑比我想象的要多。

但最后，还是爱上了这个平台。

初见：就这？

第一次用 Workers，是被朋友安利的。

他说："免费、全球加速、无限流量，写个 JS 就能跑。"

我心想，有这么好吗？

打开文档，写的第一个 Worker 是这样的：

javascript
addEventListener('fetch', event => {
  event.respondWith(new Response('Hello World!'));
});

保存，部署，等了 3 秒，访问 xxx.workers.dev。

真的亮了。

那一刻的感觉，就像第一次用上了电——这玩意是真的东西。

第一个坑：ES Module 格式

开始做稍微复杂一点的东西，想接 D1 数据库。

文档说要用 ES Module 格式。OK，改 export default。

然后开始报错。SyntaxError: Unexpected token。

查了半小时，才知道 Workers 分两种格式：

- Service Worker 格式 — 早期写法，addEventListener 那种
- ES Module 格式 — 现代写法，export default 那种

接 D1 必须用 ES Module，不能混用。

文档里有一句小字提到了，但我是真的看了三遍才发现。

第二个坑：URL 构造

部署到线上之后，发现一个奇怪的问题。

本地调试好好的，线上有些功能不正常。

追了半天，发现是 Response.redirect() 的问题。

javascript
// ❌ 这样会报错
return Response.redirect("/admin/login");
// ✅ 需要传完整 URL
return Response.redirect(new URL("/admin/login", request.url).toString());

本地环境没有域名这个概念，所以 new URL("/admin/login", "http://localhost:8787") 能正常解析。

但线上域名是 blog.woail.com，Workers 内部不认识这个路径。

这个坑，踩了我一整晚上。

第三个坑：部署覆盖数据

终于把博客跑起来了，兴冲冲地在后台写了一篇文章。

然后第二天，wrangler deploy 了一下。

文章没了。

原来，数据是硬编码在代码里的。重新部署，代码里的旧数据覆盖了 D1 数据库的修改。

又花了半小时把文章重写了一遍。

这次之后，我把数据全部迁到了 D1，后台改成读写数据库，代码里只保留演示数据。

教训：架构要一开始就定好，后期改代价很大。

爱上它的瞬间

说了这么多坑，但真正让我爱上 Workers 的，是这个场景：

有一天，我在咖啡馆改代码。手机响了，博客有个 bug 需要修。

我打开手机浏览器，进了 Cloudflare 控制台，改了改 Worker 代码，点了个"保存"。

30 秒后，博客修复了。

没有任何服务器需要连接，没有任何部署流程需要等待，代码直接在边缘节点上生效了。

那一刻我在想，这就是未来吧。

几个真心话

用 Workers 快半年了，有几句话想说：

1. 它不是万能的

Workers 适合轻量逻辑、API、静态内容。不适合 CPU 密集型任务，不适合大文件处理，不适合需要长期后台运行的东西。搞清楚它的边界，比什么都重要。

2. 免费额度很良心

每天 10 万次请求，D1 5GB 存储，R2 10GB。对于个人项目来说，基本等于不要钱。

3. 文档在变好

早期的文档确实一言难尽，但现在越来越完善。社区也很活跃，踩过的坑基本都能找到答案。

4. 冷启动快得离谱

我做过测试，从零启动一个 Worker 到响应，第一个字节的平均时间是 5-20ms。这在传统服务器上几乎不可能实现。

最后

技术选型这件事，从来没有银弹。

Workers 解决不了所有问题，但在这个"快速上线、轻量运维"的场景下，它确实是最优解之一。

我的博客，就跑在这上面。

如果你也在折腾 Web 开发，不妨试试。反正免费，也不会亏。

有问题欢迎交流。TG: @xiaokang