ElysiaJS 和 Hono 的核心選擇，懶覺比雞腿？不！是絕代雙驕

用 serverless 寫後端的人，一定常常用到 Hono 這個框架，但它可能不是你的唯一解。 香噴噴的 elysiaJS 值得你試吃看看

我手上剛好兩個都在用：Solid(ar)ity 的後端是 Hono + zod-openapi，這個部落格的 CMS 是 Elysia，兩個都跑在 Cloudflare Workers 上。用久了發現，這兩個框架長得很像，但核心的取捨完全不同。這篇不比 benchmark，比的是「它們各自把什麼當成第一優先」。

# 一句話版本

• Hono：Web 標準優先。 它的核心就是 Request 進、Response 出，所以 Workers、Deno、Bun、Node 哪裡都能跑
• Elysia：型別優先。 它的核心是讓整條路從 schema、handler 到前端 client 的型別一路接起來，Bun 是它的主場

兩個都很快、都很小，差別在它們願意為了這個優先順序犧牲什麼。

# Hono：在 Workers 上就是原生

Hono 在 Workers 上用起來最舒服的一點是：binding 直接在 context 上。

app.get('/posts', async (c) => {
  const index = await c.env.R2.get('index.json')
  return c.json(await index?.json())
})

c.env 就是這個 request 的 env，不用任何魔法。Workers 的設計本來就是「binding 跟著 request 走」，Hono 剛好就照這個模型長，所以不會跟平台打架。

驗證要嚴謹的話，加上 @hono/zod-openapi，schema 寫一次，驗證跟 OpenAPI 文件一起出來。Solid(ar)ity 後端要給別人串接，有一份自動產生的 API 文件就很重要，這也是當初選它的原因。

# Elysia：型別一路通到前端

Elysia 的賣點是 end-to-end type safety。用 TypeBox 寫 schema，handler 的參數、回傳值，甚至前端用 Eden 呼叫 API 的型別，全部自動推出來，前後端改一邊，另一邊直接紅字。

自己寫前後端都是自己的小專案時，這個體驗真的很爽，全端覺得香。部落格的後台就是 Svelte 前端直接打同一個 repo 的 Elysia API，改個欄位，TypeScript 會馬上告訴你哪裡沒跟上。

但是，Elysia 放到 Workers 上，有兩個地方要妥協：

1. 要關掉 AOT

Elysia 為了快，預設會在啟動時動態產生程式碼（AOT compile）。但 Workers 禁止 new Function / eval 這類動態程式碼，所以一定要：

new Elysia({ aot: false })

少了這行，部署上去直接噴錯。關掉 AOT 之後，Elysia 在 Workers 上就沒有它在 Bun 上那麼快了，不過對一個後台來說完全無感。

2. env 要自己傳

Elysia 沒有 c.env 這種東西。我的做法是在 Worker 的 fetch 入口用 AsyncLocalStorage 把 env 包起來：

export default {
  fetch(request, env) {
    return runWithEnv(env, () => app.handle(request))
  },
}

handler 裡再用 useEnv() 拿出來。這要開 nodejs_compat 才有 node:async_hooks。能動，但就是多了一層自己發明的東西，這種膠水寫多了，就是未來的技術債。後端如果能越輕後期因為有什麼補丁問題升級才不會遇到太多問題。

# 所以怎麼選？

我自己的選法很簡單：

說穿了，Hono 是順著平台長的框架，Elysia 是順著開發體驗長的框架。在 Workers 上，順著平台的那個會少很多摩擦；在 Bun 上，Elysia 的型別體驗很難被取代。

如果現在要我重寫部落格後台，我大概會選 Hono，少掉 AOT 跟 AsyncLocalStorage 這兩塊膠水。但當初選 Elysia 也不後悔，前後端型別一起紅字的那種快感，寫小工具真的很香。