搬家记：从 Vercel 到 Cloudflare（Nuxt 项目x2）

月底的时候，收到 Vercel 的邮件，提示我账号内有一些额度用量已经消耗 50%。我没在意，心想反正月底，马上不就归零了么？第二天起来越想越不对，我的 Vercel 是付费的 Pro 账号，计费周期是上月 22 日到本月 22 日，这才月底，才一周多，怎么会就用掉 50%？

于是我回想起之前收到 Vercel 的邮件，说以后我每个月的费用会上升 30+美金，不由得背后一凛。赶紧上 Vercel 后台查看，发现 Vercel 开始用新的计费单位：Function Invocations。且 4 月 25 日起，新开通 Pro 的用户会使用这个方式计费；而 5 月 25 日（即上月底），我们这些老 Pro 用户也会采用这个方式计价。

很明显，新计价单位比老的方式严苛很多，以至于我之前一半都用不掉的套餐费用，现在连半个月都撑不住。公平一点来说，我的项目都是 Nuxt，要走 Serverless Function，所以消耗可能比 Next.js 走 Edge Function 要高。但是，无论如何，这个价位都让我们动起了搬家的念头。目标毫无疑问，就是 Cloudflare。

具体额度可能随时有变化，我就不在这里贴数字了，简单给大家划个标准：我在 Vercel 每月 $20 的额度，大约对齐 Cloudflare 的免费版；Cloudflare 每月 $5 的套餐额度，足够我 $50 Vercel + $5 Upstash，还有一大堆我没用起来的服务。

单纯算经济帐，肯定是 Cloudflare 划算得多。但是 Vercel 行走江湖，靠的就是一手优秀的 DX，尤其在我搬家折腾完之后，更是这么觉得。整体过还比较顺利，但是坑也真没躲过去。接下来分享一些踩坑经历，希望对大家有帮助。

第一步，创建项目。在 Cloudflare Pages 导入 Git 仓库即可，操作跟 Vercel 基本一致，无需详述。接下来，我们就有了部署在 xxx.pages.dev 子域名的网站，建议测试充分之后再切换域名。

第二步，解决各种 [unenv] 问题。这个问题是由于 Cloudflare Worker 运行时精简（删掉）了一些 Node.js API 导致的。可能发生在各个环节，从部署到执行都有可能。我遇到的问题主要是：

1. ioredis。因为我使用 Upstash Redis，所以直接换 @upstash/redis/cloudflare 然后使用 http endpoint 即可解决。两者的 API 有些许区别，不过功能性差异不大，替换起来不麻烦。
2. Nitro Stroage。其实跟上面是一个问题，只不过表现不太一样。如果通过 nuxt.config.js 配置 Storage 使用 Redis，那么部署那一关都过不去……
3. crypto.createHash。这个暂时没找到好办法，主要是 TiDB Serverless 最初使用 Digest 认证，所以我才必须使用。现在他们支持 Basic Auth 认证，所以我直接去掉对这个 API 的依赖就好了。

第三步，安排 Cron job。这一步目前我也还没做好。Cloudflare Pages 不支持 Cron job，只能在 Workers 里安排 Cron Trigger。所以比较合理的做法是，建立一个统一的 cron worker，定时运行，粒度控制在比较合理的范围内，然后通过这个 worker 去调用分散在各个项目中的 cron job。

于是，由于我们暂时无法离开 Vercel 的 Cron job，所以我们就还不能关掉 Vercel 上的项目。那么我们就必须开一个分支出来进行开发。好在 Cloudflare 可以支持指定特定分支作为 Production 的做法，所以这方面也没有问题。

哦，对了，Pages 不支持在 wrangler.toml 里定义环境变量，以及我们在 Pages 里修改环境变量也不会触发重新部署，这点和 Worker 不一样，需要注意。

最后，就是改变域名指向。我们必须在 Workers & Pages > 刚才的项目 > Custom Domains 配置自定义域名，仅在在 Websites > CDN 里配置是不够的，请大家注意。另外，由于 Nuxt 是 SSR 框架，所以我们必须关闭位于 Speed > Optimization > Content Optimization 的 “Auto Minify”，否则，可能会遇到重复的页面内容。

还有一点，与 Vercel 不同，Cloudflare Pages 只包含 Edge 网络，并没有前面的 CDN 层。所以在 Cloudflare Pages 里增加缓存必须通过 Cloudflare CDN 来进行，同时 CDN 必须开启 Proxied，否则，原本在 Vercel 有效的缓存头就只能在浏览器里工作了。

以及，Cloudflare Pages 没有提供页面重定向等功能，所以原本放在 Vercel.json 里的一些东西可能就要我们自己实现了。

总结

按惯例来总结一下。Cloudflare 的套餐性价比非常高，同样用量，价格可能 Vercel 的 1/10，还能覆盖其它服务。所以值得一试。但是问题也不少，比如运行时被进一步缩减、不支持 Cron job、没有 CDN 层、没有更高层级的 Headers 控制，等等，所以在使用时，体验可能还是略逊于 Vercel。尤其是迁移搬家，更要注意。

好了，如果你对全栈开发，网站基础设施感兴趣，有问题有疑问，欢迎留言讨论。