Deno 基准测试中的 Hono：零依赖、双路由引擎的超快 Web 框架

Deno 基准测试中的 Hono：零依赖、双路由引擎的超快 Web 框架

【免费下载链接】denoA modern runtime for JavaScript and TypeScript.项目地址: https://gitcode.com/GitHub_Trending/de/deno

本文以 Deno 仓库中随基准测试数据一同维护的 Hono README 为核心，梳理 Hono 这一 Web 框架的设计定位、双路由架构、内置中间件导出体系，以及它在 Deno 基准测试体系中的角色。读完你可以掌握 Hono 的最小可运行应用写法、两套路由器的取舍依据，以及如何从 package.json 的 exports 映射理解其模块组织方式。

Hono 在 Deno 仓库中的位置：npm 基准测试数据

Hono（日语"炎"，意为火焰）是一个面向 Cloudflare Workers、Deno、Bun 等多平台的小而快的 Web 框架。当前仓库将其 vendored（内嵌）在tests/bench/testdata/npm/hono/目录下，目录内容包含：

• README.md —— 框架说明文档（本文主体来源）；
• package.json —— 完整发布元数据，含 exports 子路径映射；
• LICENSE —— MIT 许可证；
• dist/—— 构建产物，含hono.js、compose.js、context.js、request.js以及middleware/、router/、utils/子目录。

从目录结构看，该目录位于 Deno 基准测试（tests/bench/README.md 描述的cargo bench --bench deno_bench体系）的testdata/npm之下，可以推断其用途之一是为验证 npm 生态包在 Deno 中的解析与运行提供稳定的测试数据。这也正是本文以它为主线介绍 Hono 的原因：README 与真实的 dist 产物相互印证，便于把"文档描述"落到"实现证据"上。

五分钟上手：最小可运行应用

README 给出的最小示例完整如下，它展示了 Hono 的核心 API 形态——实例化Hono、注册路由、处理器直接返回响应：

import { Hono } from 'hono' const app = new Hono() app.get('/', (c) => c.text('Hono!!')) export default app

几个值得注意的细节：

• 处理器签名是(c) => ...，其中c是 Context 对象（对应 package.json 中dist/context.js与类型声明dist/context.d.ts），通过c.text()、c.json()等方法直接构造响应；
• export default app的写法与 Service Worker 运行时的入口约定一致，这正是 Hono "零依赖、仅用 Web 标准 API" 设计取向的体现；
• package.json 的scripts中包含"test:deno": "deno test --allow-read deno_test"与denoify（生成 Deno 分发的deno_dist目录），说明官方发布流程本身就把 Deno 作为一等目标平台。

核心特性：README 的五条主张

README 的 Features 章节列出了 Hono 的五个核心主张，逐条来看其在仓库文件中的对应证据：

1. Ultrafast（超快）——路由器不使用线性循环。dist 目录中存在两个独立的 router 实现：dist/router/trie-router/与dist/router/reg-exp-router/，均包含router.js、node.js、trie.js等文件。前者基于前缀树（Trie）做逐段匹配，后者把路由编译为正则表达式，两者都避免了"遍历全部路由逐条比对"的线性扫描。
2. Zero-dependencies（零依赖）——仅使用 Service Worker 与 Web 标准 API。package.json 中没有任何dependencies字段，只有devDependencies（jest、eslint、typescript、denoify 等构建工具），与"运行期零依赖"的说法吻合。
3. Middleware（中间件）——内置、自定义、第三方三级支持。dist 下的middleware/目录与 exports 映射（见下文）列出了十余个官方内置中间件；dist/compose.js则承担中间件链的组合执行逻辑（其类型声明引用了hono.d.ts中的ErrorHandler与NotFoundHandler）。
4. TypeScript——一等公民。每个 JS 产物都伴随.d.ts声明文件（如dist/hono.d.ts、dist/index.d.ts），README 顶部的 npm types 徽章也强调类型定义随包发布。
5. Multi-platform（多平台）——Cloudflare Workers、Fastly Compute@Edge、Deno、Bun 皆可运行。这一点在 package.json 的keywords（含cloudflare、fastly、deno、bun）和serve-static的三个变体导出（通用版、serve-static.bun、serve-static.module）中得到印证——静态文件中间件按运行平台拆分为不同入口。

两套路由器：Trie 与正则的基准对比

README 内置了一段官方基准数据（针对 Cloudflare Workers 场景的路由性能对比），这是理解 Hono 路由设计的关键依据：

hono - trie-router(default) x 424,449 ops/sec ±4.98% (77 runs sampled) hono - regexp-router x 516,228 ops/sec ±4.79% (81 runs sampled) itty-router x 206,641 ops/sec ±3.59% (87 runs sampled) sunder x 319,500 ops/sec ±1.33% (93 runs sampled) worktop x 187,280 ops/sec ±3.09% (87 runs sampled) Fastest is hono - regexp-router

解读要点：

• 默认路由是 trie-router（hono - trie-router(default)标注），它在增量添加动态路由时开销低，适合路由表频繁变化的场景；
• regexp-router 吞吐更高（516,228 ops/sec 对比 424,449 ops/sec），代价是路由集合变更时需要重新编译正则，适合路由固定的部署场景；
• 两者都显著快于 itty-router、sunder、worktop 等同期 Workers 路由器，验证了"不用线性循环"这一设计主张。

在 package.json 中，这两套路由器通过子路径导出对外暴露：

"./router/trie-router": "./dist/router/trie-router/index.js", "./router/reg-exp-router": "./dist/router/reg-exp-router/index.js"

类型声明同样按子路径映射（typesVersions中将router/trie-router指向./dist/router/trie-router/router.d.ts），保证 TypeScript 用户在两种选择下都能获得完整类型。使用时可在创建应用时通过new Hono({ router: RegExpRouter })之类的方式替换默认路由器（此用法来自 Hono 官方文档，README 本身仅给出默认形态）。

内置中间件与子路径导出：exports 全解

Hono 的 npm 包通过exports字段把十余个内置中间件与工具集暴露为子路径，这也是 Deno npm 解析机制需要正确处理的典型案例（条件导出 + 通配符 + 平台变体）。package.json 的完整导出面如下：

子路径	实际文件	用途
.	dist/index.js	框架主入口（Hono类）
./basic-auth/./bearer-auth/./jwt	对应dist/middleware/*/index.js	认证类中间件
./cache	dist/middleware/cache/index.js	缓存中间件
./compress	dist/middleware/compress/index.js	响应压缩
./cors	dist/middleware/cors/index.js	跨域处理
./etag/./logger/./powered-by	对应dist/middleware/*/index.js	响应头 / 日志 / 签名
./html/./jsx/./jsx/jsx-runtime/./jsx/jsx-dev-runtime	dist/middleware/jsx/*	HTML 与 JSX 渲染（含 React 兼容的运行时入口）
./pretty-json	dist/middleware/pretty-json/index.js	JSON 美化输出
./serve-static	dist/middleware/serve-static/index.js	静态文件（通用）
./serve-static.bun/./serve-static.module	bun.js/module.mjs	静态文件的 Bun 专用与 ESM 模块变体
./router/trie-router/./router/reg-exp-router	dist/router/*/index.js	两套可替换路由器
./utils/jwt/./utils/*	dist/utils/*.js	JWT 工具与通配符导出的工具集（cookie、crypto、filepath、body 等）

从 dist 目录实际文件看，utils/下确实存在cookie.js、crypto.js、filepath.js、http-status.js、encode.js等模块，与./utils/*通配导出相互对应。每个中间件的类型声明（如dist/middleware/cors/index.d.ts）都从../../hono导入Next类型，说明中间件签名被统一约束为Handler形态，这是"自定义中间件与第三方中间件可无缝混用"的结构基础。

版本与环境：v2.x 时代的 Deno 集成

• README 明确标注v2.x 已发布，并附迁移指南入口；当前 vendored 的 package.json 版本号为2.0.9，与 v2 系列一致；
• engines声明node >= 11.0.0，即最低运行时约束；在 Deno 中运行则不受该字段限制，而是由 Deno 自身的 npm 兼容性支持；
• README 顶部的 Deno 徽章指向deno.land/x/hono，表明 Hono 同时以 Deno 官方模块注册表（通过denoify脚本从同一份 TypeScript 源码生成deno_dist）分发——同一套源码经denoify转换后同时服务 npm 与 Deno 两个生态。

在 Deno 仓库中继续深入

若想在 Deno 仓库内核实本文内容，可按以下路径阅读：

• 框架说明与基准数据：tests/bench/testdata/npm/hono/README.md；
• 导出映射与元数据：tests/bench/testdata/npm/hono/package.json；
• 主类与组合逻辑：tests/bench/testdata/npm/hono/dist/hono.js、tests/bench/testdata/npm/hono/dist/compose.js；
• 两套路由器实现：tests/bench/testdata/npm/hono/dist/router/trie-router/router.js与tests/bench/testdata/npm/hono/dist/router/reg-exp-router/router.js；
• Deno 基准测试入口与过滤方式：tests/bench/main.rs 与 tests/bench/README.md。

【免费下载链接】denoA modern runtime for JavaScript and TypeScript.项目地址: https://gitcode.com/GitHub_Trending/de/deno