Hono 前后端分离系列 01：为什么用 Hono 做 API 层

前后端分离最怕的不是技术选型错，而是边界没想清楚。

很多项目一开始只是想写几个接口：

1
2
3

前端调用 API
后端返回 JSON
数据库存数据

看起来很简单。

但项目一复杂，就会开始出现问题：

接口路径越来越乱
错误格式不统一
前端不知道后端到底返回什么
跨域配置到处复制
登录状态一会儿用 token，一会儿用 cookie
本地能跑，部署后挂

这时框架本身快不快，反而不是第一问题。

真正重要的是：这个 API 层能不能长期保持清楚。

Hono 适合做前后端分离里的 API 层，不是因为它“新”，也不是因为它“轻”，而是因为它刚好站在几个关键位置上：Web Standards、TypeScript、多运行时、轻量中间件、类型安全客户端。

文档快照时间：2026-06-23。Hono 的模板、适配器和中间件会持续更新，实际项目以官方文档为准。

一、前后端分离里的 Hono 负责什么

前后端分离不是把代码放进两个仓库就完了。

更准确地说，它要分清三件事：

1
2
3

前端负责页面、交互、状态展示
后端负责业务规则、数据读写、权限校验
API 契约负责连接前后端

Hono 位于第三件事和第二件事之间。

它最适合承担：

REST API
BFF API
Webhook
管理后台接口
Serverless API
Edge API
小型业务服务
前端项目旁边的轻量后端

一个最小 Hono API 长这样：

import { Hono } from 'hono'

const app = new Hono()

app.get('/api/health', (c) => {
  return c.json({
    ok: true,
    service: 'hono-api',
  })
})

export default app

这个例子没有魔法。

请求进来，Hono 匹配路由，handler 返回 Response。你可以用 c.json() 返回 JSON，也可以直接返回原生 Response。

这就是 Hono 的一个核心优点：它没有把你带离 Web 平台太远。

二、Hono 的优势不是只有性能

很多文章介绍 Hono 时会先讲快。

快当然好，但我更关心另一件事：

1	Hono 的抽象足够薄。

它不像某些大型框架那样，一上来就要求你接受完整的目录结构、依赖注入、装饰器、模块系统。

你可以从一个文件开始：

const app = new Hono()

app.get('/api/users', listUsers)
app.post('/api/users', createUser)

也可以随着项目变大，把路由拆出去：

1
2
3

app.route('/api/users', usersRoute)
app.route('/api/posts', postsRoute)
app.route('/api/admin', adminRoute)

这对个人项目、小团队、创业项目非常友好。

前期不重，后期也有空间长大。

三、Web Standards 带来的好处

Hono 的很多设计围绕 Web Standards。

你会经常看到这些对象：

Request
Response
Headers
URL
fetch

这意味着你学到的不是某个框架的私有世界，而是更接近现代 Web 运行时的通用能力。

这点在前后端分离里很重要。

因为你的 API 可能不是永远跑在一台 Node.js 服务器上。它可能会跑在：

Node.js
Cloudflare Workers
Cloudflare Pages Functions
Bun
Deno
Vercel
Netlify
AWS Lambda

Hono 的官方文档也明确提供了多种运行时的 getting started。应用核心代码往往可以保持一致，只是入口和部署方式不同。

这让 Hono 很适合作为“可迁移的 API 层”。

四、什么时候适合用 Hono

我会在这些场景优先考虑 Hono：

前端项目需要一个轻量 API 层
想把 API 部署到 Cloudflare Workers
希望 TypeScript 从后端传到前端
不想一上来引入 NestJS 这种大型框架
项目需要兼顾 Node.js 和 Edge 运行时

比如一个 Vue / React 前端项目，后端只需要：

登录
用户信息
列表查询
表单提交
文件签名上传
Webhook 回调
管理后台接口

这类项目用 Hono 会很舒服。

你不需要为了几个接口搭一个沉重后端，也不需要把所有逻辑都塞进前端框架的 server function 里。

五、什么时候不应该用 Hono

Hono 不是万能答案。

如果你的项目本身就是大型企业后端，团队已经需要：

复杂模块系统
强依赖注入
大量后台任务
完整微服务治理
成熟的企业级约束
大团队统一开发规范

那 NestJS 之类的框架可能更合适。

如果你只是一个纯静态站点，没有接口，也没必要为了“技术栈完整”硬上 Hono。

如果你强依赖大量 Express 中间件，也要先确认迁移成本。Hono 的中间件生态在变强，但它不是 Express 的一比一替代。

六、一个合理的前后端分离架构

我比较推荐从这个结构开始：

apps/
  web/        前端：Vue 或 React
  api/        后端：Hono
packages/
  shared/     共享类型、工具函数、常量

如果你不想上 monorepo，也可以先用两个项目：

1 2	my-web/ my-api/

重点不是目录长什么样，而是职责要清楚：

页面不直接碰数据库
鉴权不只放在前端
接口入参必须校验
错误响应必须统一
前端不要猜后端返回结构

Hono 能帮你把 API 层写得很薄，但你仍然要自己保持边界。

七、这个系列会怎么讲

这一组文章会从基础到高级展开：

01 为什么用 Hono 做 API 层
02 项目结构和本地开发
03 路由、请求、响应设计
04 CORS 和前端联调
05 参数校验和错误响应
06 JWT 鉴权和权限中间件
07 数据库访问和业务分层
08 Hono RPC 类型安全客户端
09 测试、日志和可观测性
10 部署和生产架构

我会尽量避免写成“复制代码跑通就结束”的教程。

真正有价值的是理解这些问题：

为什么要这样分层？
哪里应该放业务规则？
哪里容易出安全问题？
哪些代码后面最容易失控？
怎么让前端和后端少扯皮？

前后端分离做得好，开发会很顺。

做得不好，只是把混乱从一个项目拆成两个项目。