dalao.ai

Hono

适用于任何 JavaScript 运行时的 Web 框架开源

关于 Hono

Hono 是一个用 TypeScript 写成、只依赖 Web 标准 API 的 Web 框架，同一份代码可以跑在 Cloudflare Workers、Deno、Bun、AWS Lambda 和 Node.js 等运行时上，没有任何运行时依赖。截至 2026-10-25 仓库有 32,679 个星标，最新稳定版 v4.13.14，v5 处于候选版阶段；以 MIT 授权，没有付费版。适合写边缘函数、跨运行时 API 和需要类型安全客户端的 TypeScript 团队；不适合离不开 Express 中间件生态、或必须长期停留在 CommonJS 与旧版 Node 的项目。

编辑部更新于 阅读约 10 分钟

它是什么

Hono 是一个用 TypeScript 写成的 Web 框架，GitHub 仓库简介只有一句：建立在 Web 标准之上的 Web 框架。它的请求和响应对象就是标准的 Request 与 Response，路由处理函数拿到一个 context 对象 c，返回 c.text()、c.json() 或 c.html() 的结果即可。因为只用 Web 标准 API，README 列出的运行环境包括 Cloudflare Workers、Fastly Compute、Deno、Bun、Vercel、AWS Lambda、Lambda@Edge 和 Node.js；文档侧栏还给出 Netlify、Azure Functions、Google Cloud Run、Supabase Functions 等入门页。Node.js 上需要额外装一个 @hono/node-server 适配器。

这里的 Web 标准指的是 Fetch 一族的接口：Request、Response、URL、URLSearchParams、Headers 等。Cloudflare Workers、Deno 和 Bun 本身就以这些接口为基础，所以 Hono 应用在这些平台上可以直接作为 fetch 处理函数导出；文档还写明，借助 WASI 的 wasi:http，Hono 也能跑在 WebAssembly 环境里。Node.js 的情况相反，Node.js 入门页写明 Hono 最初并不是为 Node.js 设计的，要靠适配器把 node:http 的请求转换成标准对象。

README 把卖点概括为四个词：快、轻、多运行时、自带电池。核心包没有任何运行时依赖，自带路由器、中间件、JSX 渲染、静态站点生成和一个类型安全的 RPC 客户端。官方文档列出的使用者包括 cdnjs、Cloudflare D1 和 Workers KV、Unkey、OpenStatus、Clerk 的 API 服务器和 PostHog 的 MCP 服务器，这些属于官方自述。

截至 2026-10-25，仓库有 32,679 个星标、1,427 个分支，main 分支累计 2,892 次提交，最新一次在 2026-10-25 15:17 (UTC+8)。最新稳定版 v4.13.14 于 2026-10-25 15:19 (UTC+8) 发布；下一个大版本 v5 已发出两个候选版，最近的 v5.0.0-rc.1 在 2026-10-10 20:34 (UTC+8)。npm 下载接口显示，按 UTC 统计，2026-10-16 到 2026-10-22 这一周 hono 包被下载 48,012,759 次。

Hono 是一个小巧、简单、极快的 Web 框架，建立在 Web 标准之上，可以运行在任何 JavaScript 运行时上。

Hono README（译文）

核心能力

第一是路由器可替换。Hono 内置五种路由器：RegExpRouter 把所有路由预先编译成一个大正则，匹配时不做线性循环；TrieRouter 用前缀树，支持全部路由写法；SmartRouter 在启动时从候选路由器里挑出能处理当前路由表的那个；LinearRouter 注册开销小，适合每次请求都要重新初始化应用的环境；PatternRouter 体积最小。三个预设把它们组合起来：默认的 hono 用 SmartRouter 包住 RegExpRouter 和 TrieRouter，hono/quick 面向冷启动频繁的场景，hono/tiny 追求体积，README 写它压缩后不到 12kB。

第二是内置中间件与辅助函数。内置中间件覆盖 Basic 与 Bearer 认证、JWT 与 JWK、CORS、CSRF 防护、IP 限制、请求体大小限制、缓存、压缩、ETag、日志、安全响应头、超时、请求 ID 等；辅助函数包括 Cookie、流式响应、WebSocket、代理、静态站点生成和连接信息。GraphQL、Sentry、各类认证服务的对接则放在第三方中间件里，由社区另外维护。

第三是类型推导和 RPC。路由路径里的参数会被推导成字面量类型，配合验证器（可以接 Zod）声明输入后，服务端导出应用类型，前端用 hc 客户端就能得到带类型的调用，不需要另写接口描述或生成代码。v4.12.0 给客户端加了 $path()，以及按全局中间件推导响应类型的 ApplyGlobalResponse。

第四是从 API 走向全栈。v4.0.0 的发布说明标题是“走向全栈”，加入静态站点生成、客户端组件和基于文件的路由；hono/jsx 可以在服务端渲染 HTML，也有一个浏览器端的 DOM 实现。性能上，v4.13.0 重写了 RegExpRouter，发布说明写路由注册加首次匹配约快 20%，在官方 JSON 基准测试里比上一版最多快 1.25 倍（Bun 1.4.0，Apple Silicon），同时把 HTTP QUERY 方法（RFC 10008）作为一等方法支持，并新增 Method Not Allowed 中间件。

适合谁 / 不适合谁

适合：在 Cloudflare Workers 或其他边缘函数平台上写 API 的开发者。动机页写明，作者起初就是想在 Workers 上做应用，却找不到合适的框架；冷启动、包体积和标准 API 这几项约束，Hono 从一开始就按边缘环境来设计。

适合：同一套代码要在 Deno、Bun、Node.js、AWS Lambda 等多个运行时之间迁移或同时部署的团队。业务代码只接触 Request、Response 和 context 对象，换运行时主要换入口文件和适配器。

适合：前后端都用 TypeScript、想要类型安全调用又不想维护 OpenAPI 生成流程的团队。RPC 客户端直接复用服务端的类型，改了接口前端就会编译报错。

不适合：重度依赖 Express 中间件、或者代码里大量直接操作 Node.js req/res 对象的老项目。推断：Hono 的中间件签名和请求对象都不同，Express 中间件不能直接搬过来，迁移等于重写这一层。

不适合：路由数量很多、又把整个应用放进一个 RPC 类型里的大型单体。RPC 文档的已知问题一节写明，路由越多，类型实例化越多，编辑器会变慢；前后端的 Hono 版本不一致时类型也会出错。

不适合：必须长期停留在 CommonJS 或 Node.js 22.12 以下版本的项目。v5 迁移指南写明，hono 只发布 ESM 版本，在 Node.js 上要求 22.12 或更高。

不适合：希望直接提交代码贡献的外部开发者。自 2026-10-05 起，贡献指南要求外部贡献者只提 issue，PR 限维护者提交。

和同类比

Express 是 Node.js 上的老牌 Web 框架，截至 2026-10-25 有 69,577 个星标，MIT 许可，最新版 v5.3.0 发布于 2026-10-09 20:50 (UTC+8)；同一周 npm 下载 93,967,835 次。Hono 文档拿 Express 的 572KB 安装体积和 hono/tiny 对比，这是厂商一方的比较。推断：只跑在 Node.js 上、已有大量 Express 中间件的项目，换框架的收益有限；新项目要上边缘平台或多运行时，Hono 更顺手。

Fastify 同样面向 Node.js，37,298 个星标，MIT 许可，最新版 v5.12.7 发布于 2026-10-13 16:06 (UTC+8)，同一周下载 10,082,280 次。Hono 的基准测试页把 Fastify 使用的 find-my-way 路由器列为对比对象之一，但结果只以截图给出。推断：Fastify 的插件体系和 Node.js 专属优化更成熟，偏长期运行的服务；Hono 的优势在可移植性和包体积。

迁移时还有一个折中办法：v4.13.13 加入的 hono/mount 中间件可以把其他框架的处理函数挂到 Hono 应用的某个路径下，发布说明以 itty-router 为例。推断：只要对方框架能提供接收标准 Request 的处理函数，就可以按路径逐步迁移，而不必一次性重写。

Elysia 是 TypeScript 框架，19,295 个星标，MIT 许可，最新版 1.4.30 发布于 2026-08-27 00:53 (UTC+8)，同一周下载 949,712 次。推断：Elysia 以 Bun 为主要运行时，同样强调端到端类型；只用 Bun 的团队两者都可选，要兼顾 Workers 和 Node.js 时 Hono 的覆盖面更广。

在 Workers 场景下，Hono 文档的基准测试拿 itty-router、sunder 和 worktop 对比：Hono 每秒 402,820 次操作，itty-router 为 212,598，sunder 为 297,036，worktop 为 197,345。这组数字出自 Hono 3.0.0 前后的旧版本，硬件为 M1 Pro，属于厂商自测。

上手路径

官方脚手架是 npm create hono@latest my-app（yarn、pnpm、bun 和 deno 也有对应命令），运行后按提示选择运行时模板。最小应用只有几行：new Hono() 得到应用，app.get('/', (c) => c.text('Hono!')) 注册路由，export default app 交给 Workers、Bun 或 Deno 的入口。

在 Node.js 上，模板会引入 @hono/node-server，用 serve(app) 启动。v4 文档要求 Node.js 18.14.1 以上；serve() 包装的是 node:http，返回底层服务器实例，优雅退出需要应用自行监听 SIGINT 和 SIGTERM 再调用 close()。

v5 可以通过 hono@next 提前安装，迁移指南列出了需要改的代码，主要改动是：只发布 ESM，Node.js 要求 22.12 或更高；hono/bun、hono/deno、hono/cloudflare-workers、hono/aws-lambda、hono/vercel 等运行时适配器改为独立的 @hono/* 包，hono/cloudflare-pages 直接删除；onError() 改用 (c, next) 签名，从 c.error 读取错误，抛出的非 Error 值也会进入 onError；c.req.query() 可能返回 undefined，c.req.json() 返回 unknown，c.json() 遇到无法序列化为 JSON 的值会直接报错；通配符在所有路由器里匹配规则一致。v4.13.13 已把 app.mount() 标为弃用、改用 hono/mount 中间件，这项改动在 v4 上已经可以进行。

贡献指南写明：开发用 pnpm 和 Bun，问题和改进建议通过 issue 提交。指南里另有一条 AI 使用政策：可以借助 AI，但不能浪费维护者的时间；无论是否真的用了 AI，维护者都可以不经通知关闭 issue 并封禁账号。

定价与许可证

Hono 完全免费，没有付费版或托管服务。LICENSE 是 MIT，版权方写作“Yusuke Wada and Hono contributors”。

许可证历史很简单：LICENSE 文件在仓库创建当天、2021-12-15 04:06 (UTC+8) 随提交 fbafc6e 加入；2023-01-02 18:18 (UTC+8) 的提交 c696953 把版权方从作者个人扩展为作者和全体贡献者，许可证类型没有变化。v5 拆出的 @hono/* 适配器包同样以 MIT 发布。

项目的资金来自 GitHub Sponsors，贡献指南请支持者赞助两位核心维护者 yusukebe 和 usualoma。推断：对企业用户来说，没有商业支持合同意味着出问题只能靠社区和自身能力解决。

风险与局限

安全公告。截至 2026-10-25，仓库公布的高危公告包括：2026-01-13 发布的 JWT 中间件算法混淆（默认使用 HS256，CVSS 8.2，4.11.4 修复）、2026-02-23 发布的 AWS Lambda ALB 场景下伪造客户端 IP 绕过限制（8.2，4.12.2 修复）、2026-03-03 发布的 serveStatic 任意文件读取（7.5，4.12.4 修复），以及 2026-06-09 发布的 CORS 中间件在携带凭证时回显任意来源（7.1，4.12.25 修复）。其余公告涉及中间件绕过、Cookie 与 SSE 注入、JSX 转义和请求间缓存泄露。最近一条是 2026-09-29 14:18 (UTC+8) 发布的 serveStatic 二次解码问题，4.13.11 修复。已公布的公告都填写了修复版本。

漏洞通过 GitHub 安全页面上的私下报告按钮提交。

维护集中在核心维护者身上。截至 2026-10-25，GitHub 贡献者接口显示 Yusuke Wada 有 1,772 次提交，第二位 Taku Amano 有 246 次。推断：核心维护者的时间和兴趣直接决定项目节奏，贡献指南也写明这是一个为乐趣而写的项目。

基准测试偏旧。文档里的 Workers 和 Deno 基准分别基于 Hono 3.0.0 和 Deno 1.22，硬件是厂商自己的笔记本；v4.13.0 的提速数据只和上一版比。

大版本切换有成本。v5 的 ESM 化、适配器拆包和多个 API 返回类型变化都是破坏性改动。另外，RPC 在大型应用中的编辑器性能问题写在官方文档里，属于已知限制。

来龙去脉

仓库的首个提交 4a68b0d 在 2021-12-15 03:26 (UTC+8)，GitHub 仓库在同日 04:05 (UTC+8) 创建。动机页的说法是，作者想在 Cloudflare Workers 上写应用却没有好用的框架，顺便借机学习用前缀树实现路由器；后来一位朋友贡献了 RegExpRouter，另一位写了 Basic 认证中间件，Deno 和 Bun 的支持也随之而来。

第一个发布条目 v0.0.7 在 2022-01-01 14:38 (UTC+8)。此后的大版本：v1.0.0 在 2022-04-22 08:23 (UTC+8)，v2.0.0 在 2022-07-16 17:19 (UTC+8)，v3.0.0 在 2023-02-18 22:54 (UTC+8)。2023-01-02 许可证版权方改为作者和全体贡献者。v4.0.0 在 2024-02-09 19:27 (UTC+8) 发布，加入静态站点生成、客户端组件和基于文件的路由。

2026 年，v4.12.0 在 2026-02-19 19:46 (UTC+8) 发布；2026-05-25 05:17 (UTC+8) 贡献指南加入 AI 使用政策；v4.13.0 在 2026-08-04 05:55 (UTC+8) 发布，主打性能和 HTTP QUERY 方法。2026-09-24 开发用的包管理器从 Bun 换成 pnpm；2026-10-05 15:49 (UTC+8) 的提交 d4542ee 把 PR 限定为维护者提交。2026-09-28 起 GitHub 上出现 @hono/* 适配器的独立发布条目；2026-10-08 13:15 (UTC+8) @hono/* 适配器同时发布补丁版本，让 hono@next 可以正常安装，13:56 (UTC+8) 在 GitHub 发布 v5.0.0-rc.0，2026-10-10 20:34 (UTC+8) 发出 rc.1。v4 线仍在维护，v4.13.14 于 2026-10-25 15:19 (UTC+8) 发布，修复包括让 serveStatic 只响应 GET 和 HEAD，并让适配器接受 v5 预发布版。

我们的判断

Hono 坚持“只用 Web 标准”：一个零依赖的核心、可替换的路由器、齐全的中间件和不需要代码生成的类型安全客户端，让同一套 API 能在边缘函数、Bun、Deno 和 Node.js 之间搬来搬去。官方文档列出了 Cloudflare 等厂商的使用案例。推断：npm 下载量中有一部分来自其他工具把 Hono 当作依赖间接安装，不等于直接使用的项目数。

需要放进决策的代价有三项：2026 年已有多条高危安全公告，需要及时升级；没有商业支持；维护集中在少数人手里，外部 PR 通道已经关闭。

亮点

Hono 是一个只建立在 Web 标准之上的 Web 框架，所以同一份代码可以跑在 Cloudflare Workers、Deno、Bun 和 Node 上。

Yusuke Wada 最初是为了在 Workers 上开发而做它，项目长大后依然保持简单：中间件、带类型的路由、服务端 JSX，还有一个在服务端和客户端之间共享类型的 RPC 层。

它没有任何依赖，最小的预设 hono/tiny 不到 12 kB。

资料来源

官方

  1. honojs/hono on GitHubGitHub · 访问于 2026 年 10 月 25 日
  2. Hono READMEGitHub · 访问于 2026 年 10 月 25 日
  3. Hono LICENSEGitHub · 访问于 2026 年 10 月 25 日
  4. Hono commit c696953: update license, contributors as the copyright holdersGitHub · 访问于 2026 年 10 月 25 日
  5. Hono commit 4a68b0d: Initial commitGitHub · 访问于 2026 年 10 月 25 日
  6. Hono Contribution GuideGitHub · 访问于 2026 年 10 月 25 日
  7. Hono commit d4542ee: docs(contributing): ask for issues instead of PRsGitHub · 访问于 2026 年 10 月 25 日
  8. Hono commit 0265a54: docs(contribution): add AI Usage PolicyGitHub · 访问于 2026 年 10 月 25 日