Hono 是 2026 年 OPC 构建 API 的最佳选择——<5KB bundle、5+ 运行时兼容、独有的端到端 RPC 类型安全。如果你的 OPC 产品需要 API 服务,Hono + Cloudflare Workers 的组合目前没有对手:极低延迟、全球部署、几乎免费起步。唯一需要适应的是它的社区还年轻,深水区问题可能需要自己看源码。
Hono 中间件按注册顺序执行。cors() 必须在路由之前,auth 中间件必须在受保护路由之前。错误的中间件顺序不会报错——只会静默失败。这是最常见的新手问题。
虽然 Hono 宣称 Write Once Run Anywhere,但实际存在差异:Deno 的 WebSocket API 与 Workers 不同、Node.js 适配器的性能不如原生 Workers、部分中间件仅在特定运行时可用。跨运行时部署前测试每个 target。
hono/client 的 hc 需要导入服务端类型——这意味着你的前端 bundle 会包含路由类型定义。对于简单的 landing page 或轻量 SPA,直接用 fetch() 可能更合适。
Hono 的默认错误响应是纯文本 Internal Server Error。生产环境必须用 app.onError() 自定义错误处理,记录到日志并返回结构化错误。否则调试生产问题时你将一无所知。
Hono 2022 年才发布,虽然增长极快但 StackOverflow 答案、博客教程的数量远少于 Express(2010)。复杂场景(如自定义认证中间件、非标 WebSocket 用法)可能需要读源码。
| Hono RPC 文档 | 博客文章 | - |