从 Next.js + Netlify 迁移到 TanStack + Cloudflare：一次被额度逼出来的架构升级

我们刚刚完成了项目的一次重要基础设施更新，想在这里分享一下背后的原因。简单说：我们把技术栈从 Next.js + Netlify 迁移到了 TanStack + Cloudflare。复杂一点说，这关系到带宽额度、缓慢的部署流程，以及越来越影响效率的本地开发体验。

为什么必须迁移

一开始，Next.js 部署在 Netlify 上基本够用。页面能渲染，构建能通过，用户也能正常访问。但随着使用量增长，问题开始显现：

• Netlify 免费额度成了瓶颈。 我们开始频繁碰到配额限制，没有付费会员的情况下，每一项资源都得精打细算。
• 部署速度很慢。 每次更新后，大约要等一分钟才能生效。听起来不长，但如果你一天要迭代很多次，累积起来的等待时间就很可观。
• 本地预览体验糟糕。 Next.js 本地开发服务器的启动和热更新速度都不够理想，尤其是在配置较低的机器上，反馈循环显得很沉重。

到了最后，等待和担心额度消耗的成本，已经超过了直接换技术栈的成本。

为什么选择 TanStack + Cloudflare

我们评估了几种方案，最终选择了 TanStack Start / Router 搭配 Cloudflare Workers / Pages。

• TanStack 提供了更轻量、更明确的路由和数据层。底层没有太多“魔法”，本地启动更快，调试也更直接。
• Cloudflare 的边缘网络 让部署更靠近用户。冷启动时间很短，各地响应速度都很稳定。
• 免费额度更慷慨。 对于我们这种规模的项目，Cloudflare 的免费层足以消除一直担心超额的焦虑。
• 迭代更快。 部署传播速度很快，提交修复后不再需要盯着构建队列等一分钟。

迁移过程

迁移并不是没有代价。我们需要重写路由逻辑、重新思考数据获取方式，并调整服务端逻辑的处理方式。但最终得到的是一个更清晰的架构，更贴合项目实际需求。

一些立竿见影的改善：

• 本地开发服务器从几十秒启动变成几秒启动。
• 推送代码后，改动几乎可以立刻看到。
• 再也没有收到“你已使用 80% 额度”的提醒邮件。

接下来怎么做

这次迁移不是一次临时尝试。未来所有新功能和项目都会基于 TanStack + Cloudflare 技术栈来构建。对于我们当前阶段来说，它在速度、成本控制和开发体验之间取得了最好的平衡。

如果你也在运营一个中小型项目，并且同样感受到托管平台额度带来的压力，边缘优先的部署方案值得认真考虑。