Hono的特点与适用场景

要点

• Hono 压缩后约 14KB，零外部依赖，冷启动几乎无感知
• 中间件采用 async/await 原生的洋葱模型，和 Express 的 next() 回调模式有本质区别
• 内置 Cookie、JWT、Bearer Auth、Streaming 等 Helper，不需要额外装包
• RPC 能力可以让前后端共享类型定义，减少接口对接时的手工类型维护
• 适合轻量 API 编排、边缘部署、BFF 层、Webhook 处理等场景
• 强依赖 Node.js 独占能力（文件处理、原生模块、子进程）的场景不适合 Hono

1. 核心特性速览

上一篇讲了 Hono 的设计路线和选型判断。这一篇换一个角度：把 Hono 的具体能力摊开看一遍，帮你建立一个完整的特性清单。

后面学每个模块时，你会知道自己在用哪个特性、解决什么问题。

这些特性不需要一次性全学会。先把表格存个印象，后面每一章会逐个展开。

2. 中间件模型：洋葱结构

Hono 的中间件采用 async/await 原生的洋葱模型。

先解释什么叫「洋葱模型」。假设你有两个中间件 A 和 B，请求进来时的执行顺序是这样的：

请求 → A 前半段 → B 前半段 → 路由处理 → B 后半段 → A 后半段 → 响应

像洋葱一样，一层一层往里进，再一层一层往外出。每一层都有机会在「进去」和「出来」时各做一次处理。

用代码看一下：

// logger-middleware.ts
import { Hono } from 'hono'
 
const app = new Hono()
 
// 日志中间件
app.use('*', async (c, next) => {
  const start = Date.now()
  const method = c.req.method
  const path = c.req.path
 
  console.log(`→ ${method} ${path} 开始`)
 
  await next() // 进入下一层
 
  const ms = Date.now() - start
  const status = c.res.status
 
  console.log(`← ${method} ${path} ${status} ${ms}ms`)
})
 
app.get('/', (c) => {
  return c.text('Hello')
})
 
app.get('/slow', async (c) => {
  await new Promise((r) => setTimeout(r, 100))
  return c.text('Done')
})
 
export default app

await next() 是洋葱模型的关键。这一行之前的代码在请求进入时执行，之后的代码在响应返回时执行。

访问 /slow 时，控制台输出大致如下：

→ GET /slow 开始
← GET /slow 200 102ms

中间件在请求进来时记一个时间戳，等路由处理完、响应生成后再算一次差值，就得到了处理耗时。

这种模式和 Express 的 next() 回调有什么区别？

Express 的中间件签名是 (req, res, next) => void，你调用 next() 把控制权交给下一层，但没有自然的方式在「响应返回后」再做处理。想实现日志计时，通常需要 monkey-patch res.end 或者借助额外模块。

Hono 的中间件签名是 async (c, next) => { ... }，await next() 返回的 Promise 会在整条链路执行完后 resolve。所以 await next() 之后的代码天然就是「响应后处理」。

这个差异看起来只是语法层面的，但它直接影响代码的可读性和可维护性：

• 不需要 callback 嵌套
• 错误处理可以用标准的 try/catch
• 请求前后的逻辑写在同一个函数里，不用分散到不同地方

后续第五章会专门展开中间件的写法，这里你只要记住一个核心点：Hono 的中间件是 async 函数，await next() 把请求传递给下一层，它之后的代码在响应返回时执行。

3. Helper 系统：不用额外装包就能做的事

Express 生态里，很多常见功能需要自己找中间件装：

• 解析 Cookie → cookie-parser
• 校验 Bearer Token → 自己写或找包
• 签发/验证 JWT → jsonwebtoken
• SSE / 流式响应 → 自己拼

Hono 把这些常用的能力做成了内置 Helper，直接 import 就能用，不需要额外安装依赖。

几个典型的 Helper：

// helpers-demo.ts
import { Hono } from 'hono'
import { getCookie, setCookie } from 'hono/cookie'
import { bearerAuth } from 'hono/bearer-auth'
import { sign, verify } from 'hono/jwt'
import { stream } from 'hono/streaming'
 
const app = new Hono()
 
// Cookie Helper
app.get('/visit', (c) => {
  let count = Number(getCookie(c, 'visits') ?? '0')
  count++
  setCookie(c, 'visits', String(count), { path: '/' })
  return c.text(`You visited ${count} times`)
})
 
// JWT Helper
app.post('/login', async (c) => {
  const { username } = await c.req.json()
  const token = await sign({ username, iat: Date.now() }, 'my-secret')
  return c.json({ token })
})
 
app.get('/profile', async (c, next) => {
  const token = c.req.header('Authorization')?.replace('Bearer ', '')
  if (!token) return c.json({ error: 'unauthorized' }, 401)
 
  try {
    const payload = await verify(token, 'my-secret')
    c.set('user', payload)
  } catch {
    return c.json({ error: 'invalid token' }, 401)
  }
  await next()
}, (c) => {
  const user = c.get('user')
  return c.json({ user })
})
 
// Streaming Helper - SSE
app.get('/events', (c) => {
  return stream(c, async (stream) => {
    for (let i = 0; i < 5; i++) {
      await stream.write(`data: event ${i}\n\n`)
      await stream.sleep(1000)
    }
  })
})
 
export default app

几个细节：

• hono/cookie 提供了 getCookie、setCookie、deleteCookie，直接操作 Context 上的 Cookie
• hono/jwt 提供了 sign 和 verify，返回 Promise，是 async 原生的
• hono/streaming 的 stream 函数可以方便地写 SSE 或流式响应，对 AI 场景（流式输出模型回答）非常实用

这些 Helper 和框架核心在同一个仓库里发布，版本一致，API 风格和 Context 模型完全统一。你不需要担心「这个中间件和框架版本兼不兼容」的问题。

完整的 Helper 列表在 Hono 官方文档 可以查看。后续章节会在对应场景里逐个用到。

4. RPC 能力预览

Hono 提供了一个叫 Hono RPC 的能力，可以简单理解为：后端定义好路由和返回类型，前端直接拿到完整的类型推导，不需要手动写 API 接口类型。

这里先看一个概念性的例子，第七章会完整展开。

后端代码：

// server.ts
import { Hono } from 'hono'
 
const app = new Hono()
 
app.get('/api/users/:id', (c) => {
  const id = c.req.param('id')
  return c.json({ id, name: 'Alice', email: '[email protected]' })
})
 
export default app
export type AppType = typeof app

前端代码：

// client.ts
import { hc } from 'hono/client'
import type { AppType } from './server'
 
const client = hc<AppType>('http://localhost:8787')
 
// res 的类型自动推导，data 包含 id、name、email
const res = await client.api.users[':id'].$get({ param: { id: '1' } })
const data = await res.json()
// data.name ← 编辑器自动补全，类型是 string

前端不需要手写 interface User { id: string; name: string; ... }，也不需要维护一份和后端的接口文档同步。后端改了路由或返回结构，前端编译时就能发现类型不匹配。

对一个人或小团队来说，这种能力可以省掉大量「前后端接口对不上」的排查时间。

RPC 不是 Hono 最常用的入口能力，很多人一开始用不到。但当你项目里接口变多、前后端分开维护时，它的价值会非常明显。第七章会从头搭建一个完整的 RPC 示例。

5. 适用场景地图

下面按具体场景列出 Hono 的匹配度。

几个判断原则：

适合 Hono 的信号：

• 服务逻辑主要是「接请求 → 处理 → 返回响应」
• 需要部署到边缘运行时或 Serverless 平台
• 包体积和冷启动时间是敏感指标
• 不依赖 Node.js 独有的内置模块或原生 addon

不适合 Hono 的信号：

• 需要操作本地文件系统（fs、path）
• 需要调用只能在 Node.js 里加载的原生模块
• 需要启动子进程
• 需要持久的 TCP 连接或复杂的连接池管理

这些判断标准和上一篇的选型建议是一致的，只是从「选框架」的角度换成了「看场景匹配度」。后面每做一个项目，都可以拿这个表格快速判断 Hono 是否合适。

6. 从这个系列往下看

到这里，你已经知道了 Hono 的核心特性、中间件模型、内置 Helper、RPC 概念，以及它适合哪些场景。

接下来这个系列会这样走：

1. 02.03 初始化第一个 Hono 项目 — 创建项目、写路由、本地跑、部署到 Cloudflare
2. 02.04 ~ 02.05 — 路由系统和请求处理的细节
3. 02.06 ~ 02.07 — 中间件和校验，把洋葱模型和类型推导用熟
4. 02.08 — Hono RPC 的完整实现
5. 后续章节按模块展开：数据库、认证、AI 集成、部署、测试……

每一章都建立在前面章节的基础上。如果你跳着看，至少确保先读过 02.03（项目初始化），后面的代码示例都基于那个项目结构。

下一篇：创建你的第一个 Hono 项目，从 npm create hono 开始，一路部署到 Cloudflare。

延伸阅读

• Hono 官方文档 - Features
• Hono Middleware 文档
• Hono Helper 文档
• Hono RPC 概览

总结

这一篇把 Hono 的核心特性做了一次结构化梳理：轻量和多运行时是基础，洋葱模型中间件是日常开发中最常接触的部分，内置 Helper 让你不用额外装包就能完成常见任务，RPC 能力在前后端协作时能大幅减少类型维护成本。

配合场景地图，你应该能判断自己的项目是否适合 Hono。如果适合，下一篇就直接动手建项目。