Hono 框架深度解析：为什么它被称为边缘时代的 Express

Hono 的核心设计：Web 标准优先

传统 Express 从设计之初就围绕 Node.js 的核心能力构建。它依赖 Node 的 HTTP 模块、事件机制和流处理，这些在普通服务器环境下没有问题。但到了 Cloudflare Workers、Deno Deploy 这类边缘平台，情况就变了：它们提供的往往不是完整的 Node 环境，而是一套基于 Fetch 标准的 Web API。也就是说，你依然可以用 Request/Response 处理请求，但不再有 Node 独有的 req、res 和 stream 语义。直接在这样的环境里运行 Express，通常会遇到底层依赖缺失或行为不一致的问题。

Hono 正是在这个背景下出现的。它没有试图去适配 Node 的 API，而是直接建立在 Web 标准之上。换句话说，Hono 本身就是面向边缘运行时设计的，Node.js 反而是它支持的运行时之一。这一点和 Express 有本质区别。

Hono 选择以 Web 标准为基础，并不是一种噱头。它带来的直接收益就是一次编写、多平台运行。同一个应用可以部署到 Workers、Deno、Bun，也可以跑在 Node.js 上，只需要对应的适配器即可。这让它在边缘时代具备了很强的吸引力。

从代码形态上看，Hono 看起来非常像 Express。它也提供路由、中间件、上下文对象，甚至写起来比 Express 更简洁。一个最简单的 Hono 应用如下：

import { Hono } from 'hono'
const app = new Hono()

app.use(async (c, next) => {
  const start = Date.now()
  await next()
  console.log(`${c.req.method} ${c.req.path} - ${Date.now() - start}ms`)
})

app.get('/hello', (c) => c.json({ message: 'hello' }))
app.get('/users/:id', (c) => c.req.param('id'))

export default app

注意到这里的每个处理函数都只有一个参数 c，也就是 context 对象。请求相关的内容统一挂在 c.req 上，响应则通过 c.body、c.json 等方法返回。没有 Express 中分散的 req/res 两个对象，也更容易进行类型推导。如果你熟悉 Express，切换到 Hono 的语法成本并不高。

但真正的差异在内部。Hono 的路由器基于 URLPattern 和树结构匹配，而不是简单的循环正则匹配。这意味着在路由数量增多时，性能下降会相对平缓。对于边缘场景而言，冷启动速度和请求处理延迟同样重要，Hono 在设计上把这两点都考虑了进去。

为什么 Express 在边缘环境会水土不服

理解这个问题，需要先看看边缘平台的实际约束。以 Cloudflare Workers 为例，它运行在 V8 隔离环境中，支持大部分 Web API，但不支持 Node.js 的 require 和内部模块。这意味着依赖 Node 内置模块的代码无法直接运行，比如 fs、path 以及部分 crypto 能力。Express 本身虽然不直接使用这些模块，但它的许多中间件和配套库会用到。比如我们熟悉的 serve-static 依赖 fs 和 path，在 Workers 环境下就没有办法直接使用。

即便你只是用 Express 做简单的路由转发，你也会发现它的 App 对象不是一个标准的 Request-Response 处理器，需要封装后才能被边缘平台调用。这个封装层会带来额外的兼容性风险和维护成本。

此外，边缘平台往往对包体积和执行时长有比较严格的限制。Express 应用一旦被完整打包，常常超过最小化后的 200KB 预算，而 Hono 的核心库大小只有几十 KB，配合打包工具的 tree-shaking，可以做到更小的落地体积。如果你的目标是低延迟和高并发，这一点很关键。

但这并不是说 Express 已经过时。在传统服务器环境，Express 的中间件生态和稳定性仍然是巨大优势。很多现成的鉴权、日志、模板渲染方案可以直接使用，这一点 Hono 短期内很难追上。

Hono 和 Express 的对比

下面用一个表格来梳理两者在几个关键维度的差异：

对比维度	Hono	Express
运行时要求	Web 标准，多平台支持	主要面向 Node.js
中间件生态	原生中间件较少，可适配部分	生态庞大，覆盖各类需求
路由匹配	URLPattern + 树匹配，高效	正则匹配，路由多时性能下降
包体积	核心极小，适合边缘	通常需要打包优化
类型支持	内置 TypeScript，类型推断强	基础类型，常需 @types/express
流式处理	基于 Web Streams API	基于 Node Stream，功能更丰富
适用场景	边缘函数、轻量 API、BFF	传统服务端、复杂中间件链路

需要注意的是，这张表不是要说服你用哪个，而是帮助你根据项目约束做判断。如果你的服务对吞吐量要求高，且运行在边缘平台，Hono 会是更好的起点；如果你的业务依赖大量 Node 原生的处理能力，留在 Express 才是更稳妥的选择。

Hono 适合哪些场景

在实际工程中，有几类场景使用 Hono 会明显感到顺手。

一类是边缘 API 网关。需要在 CDN 边缘聚合多个上游服务，做一些简单的鉴权、缓存、转发。Hono 的中间件可以轻松实现请求预处理，配合 fetch 转发到上游，代码非常紧凑。举个例子，假设你的产品有一个日志分析网关，原来跑在一台普通云服务器上，每天要处理百万次请求。你希望把它搬到边缘来降低首字节延迟，同时减少服务器维护成本。用 Hono 写这个转发层，原本需要自己封装 fetch 的逻辑就变成了清晰的中间件链路，很直观。

另一类是前端 BFF 层。像 Next.js 的 API Routes 或 Cloudflare Pages Functions 这类场景，本质上都是一个个独立的函数，单独用原生写法会显得零散。Hono 可以统一路由和中间件逻辑，让代码更清晰。

还有一类是低延迟的轻量 API。比如实时查询服务、指标推送接口，不需要完整的 ORM 和多级中间件，Hono 的极简设计正合适。

如果你正处在从传统 Node 服务向边缘迁移的过程中，Hono 也可以作为中间过渡层。它可以在 Node 本地跑，也可以部署到边缘，这样代码不需要重写，降低了切换风险。

实战迁移：从 Express 到 Hono 要注意什么

很多团队会在实际迁移时误以为这是一个中间件平替任务，但真正的难点往往在于处理对 Node 模块的依赖。建议先做一次依赖清单扫描：哪些中间件直接依赖 Node 内置模块，哪些只是纯粹处理请求。对于前者，需要寻找基于 Web API 实现的替代方案，Hono 官方和社区都提供了一些通用中间件，比如基本鉴权、日志、缓存等。

下面这段代码展示了一个简单的 Hono 中间件实现 token 校验的方式：

import { Hono } from 'hono'

const app = new Hono()

app.use('/api/*', async (c, next) => {
  const token = c.req.header('Authorization')
  if (!token) return c.json({ error: 'unauthorized' }, 401)
  // 校验 token，省略具体逻辑
  await next()
})

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

export default app

这个示例中的逻辑如果用 Express 写，看起来几乎一样，但底层的请求模型不同。Hono 的 c.req.header 直接基于 Headers API，不会受到 Node 版本差异的影响。这保证了在本地开发和边缘部署时行为一致。

另一个容易遗漏的点是超时设置。Express 在 Node 中可以使用 server.timeout 控制超时，但在边缘平台通常没有直接的设置接口。你需要依赖平台配置，或者在应用层实现 AbortSignal 来控制请求的生命周期。Hono 因为标准化的 Request/Response，和 fetch API 配合顺畅，所以实现起来更优雅。