Hono 工程化实战 05：Cloudflare、Node、Bun、Deno 部署怎么选

Hono 最大的吸引力之一，是它能跑在很多 JavaScript runtime 上。

你可以写一套类似的代码，然后部署到：

1
2
3
4
5
6
7
8

Cloudflare Workers
Cloudflare Pages
Node.js
Bun
Deno
Vercel
Netlify
AWS Lambda

这很灵活。

但灵活也会带来选择困难。

很多人会问：

1
2
3
4
5

Hono 到底应该部署在哪里？
Cloudflare Workers 适合所有场景吗？
Node.js 会不会太老？
Bun 能不能直接上生产？
Deno 适合什么项目？

这篇文章不做玄学排名。

我们从项目需求出发，聊 Hono 的运行时和部署选择。

技术栈快照时间：2026-06-23。Hono adapter、Cloudflare Workers、Node/Bun/Deno 支持方式会更新，生产使用前以官方文档为准。

一、先看 Hono 的底层优势

Hono 基于 Web 标准。

核心是：

1
2
3
4
5
6

Request
Response
fetch
Headers
URL
ReadableStream

这让它比很多传统 Node 框架更容易跨 runtime。

一个最小 Hono app：

1
2
3
4
5
6
7

import { Hono } from 'hono'

const app = new Hono()

app.get('/', (c) => c.text('Hello Hono'))

export default app

在很多平台上，这个 app.fetch 都能作为入口。

但注意：

1
2

框架代码可移植
不代表你的应用完全可移植

一旦你用了特定平台能力，比如 D1、KV、R2、Node fs、Bun.file，迁移成本就出现了。

二、Cloudflare Workers 适合什么

Cloudflare Workers 很适合：

1
2
3
4
5
6
7
8

轻量 API
边缘接口
前后端分离 BFF
Webhook
缓存层
鉴权网关
全球用户访问
和 D1/KV/R2/Queues 组合的应用

Hono 在 Workers 上的入口通常很简单：

1
2
3
4
5
6
7
8
9

import { Hono } from 'hono'

const app = new Hono<{ Bindings: Env }>()

app.get('/api/health', (c) => {
  return c.json({ ok: true })
})

export default app

使用绑定：

1
2
3
4
5
6
7
8
9

app.get('/api/posts/:id', async (c) => {
  const post = await c.env.DB.prepare(`
    select id, title
    from posts
    where id = ?
  `).bind(c.req.param('id')).first()

  return c.json({ data: post })
})

Workers 的优势是：

1
2
3
4
5

部署简单
全球边缘网络
和 Cloudflare 存储产品集成好
冷启动体验通常不错
很适合轻量 HTTP API

但它也不适合所有场景。

三、Workers 的边界

如果你的项目强依赖这些能力，要谨慎：

1
2
3
4
5
6

本地文件系统长期读写
长时间 CPU 计算
传统 TCP 连接模型
大量 Node.js 原生模块
复杂后台常驻进程
需要完整 Linux 环境

Workers 是 serverless/edge 模型。

它适合请求驱动，不适合把它当成一台长期运行的 VPS。

如果你的项目是：

1
2
3
4
5

视频转码
大型爬虫
复杂图片处理
长时间任务调度
依赖很多 native addon

那 Node.js 服务、容器或专门任务系统可能更合适。

不要因为 Hono 能跑在 Workers，就把所有东西都塞到 Workers。

四、Node.js 适合什么

Node.js 仍然是最稳妥的选择之一。

适合：

1
2
3
4
5
6
7

传统后端 API
需要完整 npm 生态
需要连接 MySQL/Postgres/Redis
需要文件系统
需要自建部署
需要长连接服务
需要后台 worker 进程

Hono 跑在 Node.js 上通常用 @hono/node-server：

1
2
3
4
5
6
7
8
9
10
11

import { serve } from '@hono/node-server'
import { Hono } from 'hono'

const app = new Hono()

app.get('/', (c) => c.text('Hello Node'))

serve({
  fetch: app.fetch,
  port: 3000,
})

Node.js 的优势是：

1
2
3
4
5

生态成熟
部署方式多
调试工具多
团队经验多
和传统数据库连接模型兼容好

如果你要做一个面向国内服务器、MySQL、Redis、对象存储的常规业务 API，Node.js + Hono 是很务实的组合。

五、Node.js 部署建议

Node.js 自建部署时要关心：

1
2
3
4
5
6
7

进程管理
反向代理
日志收集
健康检查
优雅关闭
环境变量
数据库连接池

常见结构：

1
2
3
4
5
6
7

Nginx/Caddy
   |
   v
Node.js Hono API
   |
   v
Postgres/MySQL/Redis

生产入口不要直接依赖默认端口：

1
2
3
4
5
6

const port = Number(process.env.PORT ?? 3000)

serve({
  fetch: app.fetch,
  port,
})

健康检查：

1
2
3
4
5
6

app.get('/health', (c) => {
  return c.json({
    ok: true,
    runtime: 'node',
  })
})

如果用 Docker，再配合容器健康检查。

Node.js 不是不现代。

它只是更像一台你要认真运维的服务器。

六、Bun 适合什么

Bun 的吸引力是速度和工具链整合。

适合：

1
2
3
4
5

新项目
内部工具
性能敏感但依赖可控的 API
团队愿意接受较新运行时
希望简化包管理和启动速度

Hono 在 Bun 上可以直接运行：

1
2
3
4
5
6
7

import { Hono } from 'hono'

const app = new Hono()

app.get('/', (c) => c.text('Hello Bun'))

export default app

Bun 的优点：

1
2
3
4

启动快
工具链体验好
TypeScript 支持友好
性能表现积极

但生产选择 Bun 时要确认：

1
2
3
4

依赖是否兼容
团队是否熟悉
监控和部署链路是否准备好
出现 runtime bug 时是否能处理

对核心业务，我会先在非关键服务或内部服务上试 Bun。

不是因为 Bun 不好，而是因为生产稳定性需要实际验证。

七、Deno 适合什么

Deno 的特点是 Web 标准、安全模型、TypeScript 体验。

适合：

1
2
3
4

偏现代 Web 标准的服务
脚本和工具服务
对权限模型有要求的项目
部署到 Deno Deploy 的轻量 API

Hono 在 Deno 上可以：

1
2
3
4
5
6
7

import { Hono } from 'hono'

const app = new Hono()

app.get('/', (c) => c.text('Hello Deno'))

Deno.serve(app.fetch)

Deno 的优点：

1
2
3
4

Web 标准一致性好
TypeScript 体验好
默认安全模型清晰
工具链统一

但如果你的团队和生态主要在 Node.js，Deno 的迁移收益不一定足够大。

选择 runtime 要看团队和依赖，不只看技术审美。

八、跨 runtime 要抽象平台能力

如果你希望 Hono app 将来能迁移，不要在业务代码里到处写平台 API。

错误示例：

1
2
3
4

app.get('/api/posts', async (c) => {
  const rows = await c.env.DB.prepare('select * from posts').all()
  return c.json({ data: rows.results })
})

这会把 route 和 Cloudflare D1 绑死。

更好的方式：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

type PostRepository = {
  list(): Promise<Array<{ id: string; title: string }>>
}

function createApp(deps: { posts: PostRepository }) {
  const app = new Hono()

  app.get('/api/posts', async (c) => {
    const posts = await deps.posts.list()
    return c.json({ data: posts })
  })

  return app
}

Cloudflare 实现一套 repository。

Node.js 实现另一套 repository。

业务 route 不关心底层是 D1、Postgres 还是 SQLite。

这就是可移植性的真实成本。

九、怎么选择

可以用这个表判断：

我的默认建议：

1
2
3

如果你已经在 Cloudflare 生态里，用 Workers
如果你是常规后端业务，用 Node.js
如果你想尝试新 runtime，从非核心服务开始用 Bun/Deno

不要为了技术新鲜感牺牲可维护性。

十、部署前检查清单

不管部署到哪里，都要检查：

1
2
3
4
5
6
7
8
9
10

环境变量是否完整
secret 是否没有写进代码
日志是否能查
错误是否有 requestId
健康检查是否可用
CORS 是否按环境配置
数据库连接是否稳定
静态资源和 API 域名是否明确
构建产物是否可复现
回滚方案是否明确

Hono 的部署入口很轻。

但生产部署不是只有入口文件。

它还包括：

1
2
3
4
5
6
7

配置
日志
监控
数据库
网络
回滚
安全

Hono 给你的是跨 runtime 的自由。

你要补上的是每个 runtime 背后的工程约束。