Hono：跑在所有 JS 运行时上的边缘 Web 框架

Hono（在日语中意为“火焰”🔥）是一个“small, simple, and ultrafast”的 Web 应用框架，由 Yusuke Wada 发起、自 2022 年起以 MIT 协议开源。它最核心的主张不是某一个运行时，而是只使用 Web Standard API——官方首页一句话概括：“Fast, lightweight, built on Web Standards. Support for any JavaScript runtime.”。本文基于 hono.dev 官方文档、GitHub 仓库与官方基准页面，分析它的设计机制、性能口径，以及它与本博客此前写过的 Elysia 到底差在哪。

一、背景：边缘运行时需要什么样的框架

过去几年，Cloudflare Workers、Fastly Compute@Edge、Deno Deploy、Vercel Edge Functions 这类“边缘 Serverless”平台快速流行。它们和传统 Node.js 服务器有几个本质不同：

• 冷启动敏感：函数可能在全球数百个节点上被临时拉起，包体积每多 100KB 都会拉长冷启动；
• 运行时不是 Node：它们实现的是 Web Fetch API（Request/Response），而不是 Node 的 http 模块，Express 那套 (req, res) => {} 抽象根本跑不起来；
• 没有长驻进程：你不能假设一个内存里的全局连接池能一直活着。

Express、Fastify 这些为 Node 长驻服务器设计的框架，搬到边缘后要么跑不动，要么包体积巨大。Hono 就是冲着这个空白来的：用浏览器和边缘运行时都认识的 Request/Response 写一次代码，同一份产物丢到 Cloudflare、Fastly、Deno、Bun、Vercel、AWS Lambda/Lambda@Edge 或 Node 上都能跑。

二、是什么：基于 Web Standards 的微型框架

Hono 的极简 API 长这样：

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

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

export default app

c 是一个 Context 对象，封装了请求、响应、中间件变量和运行时相关的绑定。官方反复强调几个卖点：

• 零依赖、只用 Web Standard API：GitHub README 写明 “Hono has zero dependencies and uses only the Web Standard API”；
• hono/tiny 预设体积极小：README 称 hono/tiny preset 在 12KB 以下，官网首页写作 under 14kB（两处口径略有差异，均为 gzip 前的打包体积量级）；
• Batteries Included：内置 logger、CORS、ETag、JWT、Bearer 认证、静态资源、校验等中间件，以及服务端 JSX 渲染器；
• 一等 TypeScript：路由路径本身可以是类型化的，配合 hc 客户端可获得类似 tRPC 的端到端类型提示。

三、技术机制：为什么 RegExpRouter 快

Hono 的性能故事几乎全押在路由层。官方提供四种路由器，由 Taku Amano 实现：RegExpRouter、SmartRouter、LinearRouter、PatternRouter。其中 RegExpRouter 是招牌。

普通路由库（包括 Fastify 内部的 find-my-way）通常用树（radix tree）或线性遍历匹配路径；RegExpRouter 的做法不同——它把所有已注册路由编译成一条巨大的正则表达式，一次匹配就把路径参数全部捕获出来，避免了逐条线性循环。官方在 benchmarks 页的原话是 “Not using linear loops. Fast.”。

上图是官方在 Node.js 上做的路由器微基准之一（short static，命中 GET /user）：

在 long static（深层嵌套路径 /very/deeply/nested/route/hello/there）场景下，RegExpRouter 仍为 85.81 ns/iter，而 TrieRouter 掉到 354.22 ns、find-my-way 214.42 ns、express 988.03 ns——路径越深，正则预编译的优势越明显。

四、关键数据：跨运行时的吞吐

除了路由器微基准，官方还在三个真实运行时上给了全框架吞吐：

官方在 Workers 段的结论是 “Hono is the fastest, compared to other routers for Cloudflare Workers”。

五、评测方法批判：这些数字该怎么打折

必须把口径说清楚，否则容易被首页的“ultrafast”带偏：

1. 路由器微基准测的是“查表”，不是“请求处理”。上面的 ns/iter 只是路由匹配这一步，没有序列化、没有业务逻辑。注意图里 express 一行专门标了 WARNING: includes handling——它是唯一一个把请求处理也算进去的对象，其余路由库只测匹配，所以“快 express 9.9×”的对比其实并不对称，框架间真实业务吞吐差距远没有这么夸张。
2. 跨运行时数据普遍偏旧。Deno 那组用的是 Hono 3.0.0 + Deno v1.22（2022 年），Workers 组也是早期版本。Hono 已迭代到 4.x/5.x，对比框架（oak、itty-router 等）同样在演进，倍数不能平移到今天。
3. RegExpRouter 不是万能的。把所有路由编译成一条大正则有代价：它不支持全部路由形态（例如复杂的多参数、通配符混用等边界模式）。这正是 Hono 默认提供 SmartRouter 的原因——官方会先判断当前路由表能否用 RegExpRouter，能就用最快的，不能就自动回退到 LinearRouter。也就是说，“默认最快”是有条件的。
4. 官方自测：所有数字都来自 Hono 团队自己维护的 benchmarks/ 目录，属于官方自测，不是 TechEmpower 那种第三方中立榜单。

换句话说，Hono 证明的是“在边缘这种冷启动敏感、包体积敏感的环境里，框架本身几乎不添麻烦”，而不是“你的业务 API 一定比别人快十倍”。

六、与 Elysia 的分工：别把它们当成竞品

本博客此前写过 Elysia。两者都是 TypeScript 后端框架、都快、都主打 DX，但定位刻意错开：

• Elysia 把宝押在 Bun：最快成绩来自 Bun 运行时，核心叙事是“Schema 即唯一真相源”——一份 Schema 同时做运行时校验、类型推导、OpenAPI 文档和端到端客户端类型（Eden Treaty）。它更像“Bun 上的全栈类型安全框架”。
• Hono 把宝押在 Web Standards：不绑定任何运行时，卖点是“同一份代码上云边缘”，路由层极致轻量，中间件与 JSX 渲染器丰富。它更像“边缘/多运行时的微型路由+中间件框架”。

一句话：要在 Cloudflare Workers / Fastly / Deno Edge 上跑，或者要一份代码部署到多个边缘平台，选 Hono；全力投入 Bun、想要端到端 Schema 类型安全，看 Elysia。

七、优势与局限

优势：

1. 真正的一次编写、处处部署：Web Standards 抽象让它在 Workers/Fastly/Deno/Bun/Node 间无缝迁移，这是 Express/Fastify 给不了的；
2. 包体积与冷启动友好：hono/tiny 不到 12–14KB、零依赖，对边缘函数冷启动是实打实的收益；
3. 路由层性能顶尖：RegExpRouter 在匹配这个微观环节确实领先主流路由库；
4. 中间件生态齐全：内置 + 第三方中间件覆盖认证、CORS、日志、校验等常见需求，服务端 JSX 可配合 htmx 做无客户端 JS 的 SSR 应用。

局限：

1. 最快的路由有条件：RegExpRouter 不支持全部路由模式，复杂路由表下会自动降级，“最快”并非全程成立；
2. 官方基准偏旧且为自测：Deno/Workers 数据停留在 2022–2023 年版本，跨语言、跨业务的真实性能需要自己压测；
3. 没有 Elysia 那样的 Schema 全家桶：Hono 负责路由与中间件，校验、ORM、端到端类型仍需自己组合 Zod/Valibot 等；
4. 边缘语境下的约束依旧存在：长连接、原生 TCP、大块内存计算这些边缘运行时本身不擅长的事，换框架也解决不了。

八、谁该关注

• 要把 API 或 SSR 应用部署到 Cloudflare Workers / Fastly / Deno Edge 的团队：Hono 几乎是这类场景的事实标准之一，同一份代码还能在本地 Node/Bun 跑；
• 被冷启动和包体积折磨的 Serverless 开发者：不到 14KB、零依赖的体积收益直接落在钱和延迟上；
• 想要一个比 Express 更现代、但又不想绑死 Bun 的 TS 团队：Hono 是温和迁移路径。

反之，如果你只跑一台长驻 Node 服务器、重度依赖 Express 中间件生态，或者最看重“Schema 驱动的端到端类型安全”，那 Fastify 或 Elysia 可能更对口。建议把 Hono 放进技术选型清单后，用你自己的真实路由（带 DB、带序列化）在目标边缘平台压一次，再下结论。

参考来源

• Hono 官方网站
• Hono 官方基准文档
• GitHub 仓库 honojs/hono
• Koala 项目库条目：Hono | 面向边缘场景设计的 Web 框架