Hono.js 邊緣運算後端框架入門教學：取代 Express 的超輕量選擇

我知道講這話可能會得罪一些人，但 Express 真的該退休了。它在 2010 年發布的時候確實是一個偉大的框架，但到了 2026 年，它幾乎沒有進化——不原生支援 TypeScript、沒有 Edge Runtime 的概念、中介軟體的架構設計也顯得過時。問題是，很多人因為「大家都在用」就繼續用，卻沒去看看外面的世界有多精彩。

Hono.js 就是那個讓我重新愛上寫後端的框架。不到 12KB 的體積、原生 TypeScript 支援、跑在任何 JavaScript runtime 上——它不只是 Express 的替代品，而是一個全新世代的後端框架。

為什麼要換掉 Express

先來聊聊 Express 的痛點，這些你應該或多或少都遇過：

• TypeScript 支援很差：Express 的型別定義是社群維護的 @types/express，經常有型別不完整或錯誤的問題。Request 和 Response 的泛型支援也很弱，寫 TypeScript 的時候常常需要手動斷言型別。
• 不支援 Edge Runtime：Express 依賴 Node.js 的 http 模組，所以它只能跑在 Node.js 上。你沒辦法把它部署到 Cloudflare Workers、Deno Deploy、或 Vercel Edge Functions。
• 中介軟體機制老舊：Express 的 middleware 是基於回呼函式的，雖然你可以用 async/await，但錯誤處理的方式還是停留在 next(err) 的年代。
• 效能瓶頸：Express 的路由匹配是線性的，當你的路由數量很多的時候，效能會明顯下降。

我不是在唱衰 Express——它在歷史上的貢獻毋庸置疑。但作為一個後端工程師，繼續用一個十多年前設計的框架來應對現代需求，實在有點不合理。如果你對後端架構有興趣，也推薦看看 PostgreSQL 17 JSON_TABLE 教學，在資料庫層面做好基礎。

Hono.js 核心特色

Hono（日文「炎」的意思）是由 Yusuke Wada 在 2022 年創建的，一開始是為了 Cloudflare Workers 而設計，後來擴展到支援所有主流的 JavaScript runtime。截至 2026 年初，GitHub 上已經有超過 25,000 個 star，npm 每週下載量超過 200 萬次。

多 Runtime 支援

這是 Hono 最強大的特色之一。你寫的程式碼可以不做任何修改就跑在：

• Cloudflare Workers / Pages
• Bun
• Deno / Deno Deploy
• Node.js（透過 @hono/node-server）
• AWS Lambda
• Vercel Edge Functions
• Fastly Compute

這意味著你可以用同一套程式碼，根據需求選擇不同的部署目標。開發階段用 Bun（啟動超快），生產環境部署到 Cloudflare Workers（全球邊緣節點），測試用 Node.js——完全不用改程式碼。

超小的 Bundle Size

Hono 的核心只有不到 12KB（gzip 後），而且零依賴。相比之下，Express 安裝後的 node_modules 大概是 1.8MB。在 Edge Runtime 環境下，bundle size 直接影響冷啟動速度，Hono 在這方面有絕對的優勢。

安裝與快速開始

用 Bun 建立一個新的 Hono 專案：

bun create hono my-api
cd my-api
bun install

或者如果你想手動設定：

mkdir my-api && cd my-api
bun init
bun add hono

建立一個基本的 API server：

import { Hono } from 'hono'

const app = new Hono()

app.get('/', (c) => {
  return c.json({ message: '你好，Hono！' })
})

app.get('/users/:id', (c) => {
  const id = c.req.param('id')
  return c.json({ id, name: `User ${id}` })
})

export default app

注意看——不用 listen()、不用指定 port。Hono 會根據 runtime 自動處理這些細節。在 Bun 裡跑 bun run dev 就好了。

路由與 Middleware

Hono 的路由系統是基於 Trie 樹的，效能比 Express 的線性搜尋快非常多。當你有上百條路由的時候，差異會特別明顯。

路由分組也很直覺：

const api = new Hono()

api.get('/users', listUsers)
api.post('/users', createUser)
api.get('/users/:id', getUser)

const app = new Hono()
app.route('/api/v1', api)

Middleware 的寫法也很優雅：

import { cors } from 'hono/cors'
import { logger } from 'hono/logger'
import { jwt } from 'hono/jwt'

app.use('*', cors())
app.use('*', logger())
app.use('/api/*', jwt({ secret: 'my-secret' }))

Hono 內建了超過 20 個常用的 middleware，包括 CORS、JWT 驗證、Rate Limiting、壓縮、快取控制等等。你幾乎不需要安裝額外的套件。這跟 Express 那種什麼都要自己裝的哲學完全不同。

說到後端架構，如果你正在考慮微服務或平台工程的方向，可以參考 Platform Engineering 平台工程實踐 這篇文章，裡面有不少跟 API Gateway 相關的實踐經驗。

RPC 型別安全

這是我最愛的功能。Hono 內建了 RPC 機制，讓你的前後端可以共享型別定義，實現端到端的型別安全。

在 server 端定義路由：

const routes = app
  .get('/api/posts', async (c) => {
    const posts = await db.query('SELECT * FROM posts')
    return c.json(posts)
  })
  .post('/api/posts', async (c) => {
    const body = await c.req.json()
    const post = await db.insert('posts', body)
    return c.json(post, 201)
  })

export type AppType = typeof routes

在 client 端（例如 React、Svelte 前端）直接匯入型別：

import { hc } from 'hono/client'
import type { AppType } from '../server'

const client = hc<AppType>('http://localhost:3000')

// 這裡的 res 會自動推導出正確的型別
const res = await client.api.posts.$get()
const posts = await res.json()

不需要 OpenAPI、不需要 code generation、不需要 GraphQL——型別就是自動同步的。搭配 Prisma ORM 全端開發指南 裡介紹的 type-safe ORM，你可以建立一個從資料庫到前端完全型別安全的全端應用。

部署到 Cloudflare Workers

如果你選擇 Cloudflare Workers 作為部署目標（我強烈推薦），設定非常簡單：

# wrangler.toml
name = "my-api"
main = "src/index.ts"
compatibility_date = "2026-01-01"

然後一行指令部署：

npx wrangler deploy

就這樣。你的 API 會被部署到全球超過 300 個邊緣節點，使用者不管在哪裡都能得到低延遲的回應。Cloudflare Workers 的免費方案每天有 100,000 次請求額度，對於個人專案或小型應用來說完全夠用。

如果你的應用需要資料庫，Cloudflare 的 D1（SQLite at the edge）跟 Hono 的整合非常好。或者你也可以用 KV Storage 來做快取。

結論

回到一開始的問題：該換掉 Express 嗎？我的答案是肯定的，但有前提。

如果你正在維護一個成熟的 Express 專案，而且它運作得很好，沒必要為了換而換。但如果你要開新專案，或者你的專案需要部署到 Edge Runtime，Hono 絕對是目前最好的選擇。

學習曲線幾乎為零——如果你會 Express，你五分鐘就能上手 Hono。而 Hono 帶來的好處——多 runtime 支援、RPC 型別安全、更好的效能、更現代的 API 設計——是 Express 不可能追上的。

最後提醒一點：框架只是工具，重要的是你用它來解決什麼問題。不管你選 Hono 還是繼續用 Express，把 API 設計做好、把錯誤處理做對、把監控做到位，才是後端工程師最該關注的事。