珠海项目 - tRPC + Bun 自托管 vs CF Workers 对比

6/17/2025

性能、部署、开发体验，我们做了一轮完整的比对。

在开发珠海旅游后台系统的过程中，我们面临一个关键的后端架构抉择：

是采用 tRPC + Bun 自托管，还是继续使用 Cloudflare Workers + KV/D1？

为了做出合理决策，我们分别就以下几个维度进行了对比：

🧪 性能（首次响应 + 并发）

• Bun + tRPC（自托管）

  • 启动快，首次响应 < 20ms
  • 并发表现优于传统 Node，接近 Go 等语言性能
  • 需要国内部署服务器做加速

• Cloudflare Workers

  • 全球边缘节点，国内访问视网络情况波动较大
  • 较小请求体响应迅速，但 KV 读取存在冷启动延迟（约 30~100ms）

结论：本地服务更可控，Workers 更轻便但受制于边缘网络波动。

⚙️ 部署 & 运维

• 自托管

  • 我们测试了 Railway 和 Vercel Bun Runtime，国内速度不稳定
  • 阿里云轻量服务器可以解决访问问题，但带来额外运维负担
  • 数据库连接需自行搭建/运维（PostgreSQL）

• Cloudflare Workers

  • 自动部署到全球，无需服务器管理
  • KV、D1、Queues 等服务组件开箱即用
  • 部署稳定性强、适合 MVP 阶段

结论：前期 MVP 阶段 Cloudflare 更友好，自托管适合后期控制成本或访问保障。

🧑‍💻 开发体验

• tRPC + Bun

  • 完整类型推导 + API 与前端强绑定，体验极佳
  • 适合我们 Solid 前端生态，无需 REST/GraphQL

• Workers

  • 类型补全偏弱，需自己定义 CfRequest 类型
  • 数据模型设计需贴合 KV 或 D1 的限制

结论：开发体验上 tRPC 明显胜出，Workers 更适合轻量请求或边缘任务。

当前决定 ✅

我们将在 MVP 阶段使用 Cloudflare Workers，先实现基础功能与数据收集，并规避国内访问问题。
PoC 验证完成后，若用户量上升且有自建要求，再考虑迁移至自托管 Bun + tRPC 方案。

这两种架构我们会保持同步构建，视客户最终预算与需求做最终选型。