全书目录

第三十四篇：Hono 完全指南 —— 边缘轻骑哨站宇宙

第九站：跨运行时，是 Hono 最值钱的“战马”

2 分钟 490 字 第 645 / 962 个阅读单元

很多同学以为 Hono 的亮点只是“语法漂亮”。

不是。

它真正贵的地方在于：你写的是一份哨站蓝图，而不是某个驻地专用的地堡说明书。

#统一业务层，分离驻地入口

ts
// app.ts
import { Hono } from 'hono'

export const app = new Hono().get('/', (c) => c.text('统一哨站蓝图'))
ts
// node-entry.ts
import { serve } from '@hono/node-server'
import { app } from './app'

serve(app)
ts
// worker-entry.ts
import { app } from './app'

export default app

这套结构的好处非常现实：

  • 本地先跑 Node
  • 线上再落 Cloudflare
  • 或者同一套逻辑分别驻扎不同平台

#统一拿环境变量：env(c)

ts
import { Hono } from 'hono'
import { env, getRuntimeKey } from 'hono/adapter'

const app = new Hono()

app.get('/runtime', (c) => {
  const { APP_NAME } = env<{ APP_NAME: string }>(c)

  return c.json({
    appName: APP_NAME,
    runtime: getRuntimeKey(),
  })
})

这个设计的核心思路是：

  • 在 Node/Bun 下，可能来自 process.env
  • 在 Cloudflare 下，可能来自 bindings
  • 你尽量用统一接口去拿

#一个成熟判断：先写 Web Standard，再碰运行时私货

这句话非常重要。

如果你一上来就在业务层到处写：

  • Node 原生 socket
  • 某平台私有 request 属性
  • 某边缘平台独占对象

那你等于自己把轻骑哨站焊死成固定地堡。

Hono 的正确使用姿势是：

  1. 先用标准 Request/Response 思维写通用业务
  2. 只有在确实需要时，再下沉到运行时特定能力

例如 Node 需要更底层能力时，官方也有 @hono/node-server 的绑定类型可用。但那应该是例外能力，不是默认写法。