冷啟動100毫秒 vs 2-5秒，同一套代碼跑在Lambda、Bun、Cloudflare Workers上不用改——這不是性能測試數(shù)據(jù)，是我們遷移后的真實生產(chǎn)環(huán)境對比。

我們團隊用NestJS搭過企業(yè)級系統(tǒng)（Vendure底層就是NestJS，我們確實喜歡它）。但新項目啟動時，我們選了Hono。不是NestJS不行，是它給的東西我們這次不需要。

15個端點的API，真的需要裝飾器、模塊、提供者、Angular那套依賴注入容器嗎？答案很清楚。這篇文章是同時跑過三個框架的人寫的誠實對比。

為什么選Hono：不是更輕，是更對

Hono是個為邊緣計算設(shè)計的Web框架。Node.js、Bun、Deno、Cloudflare Workers、AWS Lambda、Vercel Edge、Fastly——同一份代碼，零改動部署。

核心14KB。Lambda冷啟動壓到100毫秒以內(nèi)。NestJS冷啟動2-5秒。對Serverless場景，這差距就是用戶體驗本身。

Hono不給架構(gòu)意見。路由、中間件、上下文給你，服務怎么組織、倉庫放哪、業(yè)務邏輯怎么拆，你自己定。5-50個端點的中小型API，這剛剛好。20條路由不需要模塊系統(tǒng)。

我們實際這么寫：

import { Hono } from 'hono';

import { cors } from 'hono/cors';

import { jwt } from 'hono/jwt';

import { logger } from 'hono/logger';

const app = new Hono();

// 中間件

app.use('*', logger());

app.use('*', cors({ origin: ['https://app.example.com'] }));

app.use('/api/*', jwt({ secret: process.env.JWT_SECRET! }));

// 路由

app.get('/api/products', async (c) => {

const products = await productService.findAll();

return c.json({ data: products });

app.get('/api/products/:id', async (c) => {

const product = await productService.findById(c.req.param('id'));

if (!product) return c.json({ error: 'Not found' }, 404);

return c.json({ data: product });

app.post('/api/products', async (c) => {

const body = await c.req.json();

const product = await productService.create(body);

return c.json({ data: product }, 201);

export default app;

三行中間件，三條路由，沒有裝飾器，沒有模塊聲明，沒有依賴注入配置。這就是全部。

運行時可移植性：Hono的真正護城河

我們同一套Hono代碼庫，Lambda（API Gateway）、Bun（容器）、Cloudflare Workers（邊緣）三地跑。運行時之間零代碼改動。

這是Hono獨有的能力。其他框架做不到。

對基礎(chǔ)設(shè)施團隊，這意味著什么？選型時不用賭。今天跑Lambda，明天切Bun，后天試邊緣——業(yè)務代碼不用重寫。遷移成本從"重構(gòu)項目"變成"改部署配置"。

tRPC集成是我們另一個高頻場景。Hono + tRPC，TypeScript全棧，端到端類型安全，不用GraphQL：

import { trpcServer } from '@trpc/server/adapters/fetch';

import { appRouter } from './router';

app.use('/trpc/*', trpcServer({ router: appRouter }));

客戶端調(diào)用的每個接口，類型從服務端自動推導。改服務端簽名，客戶端編譯時報錯。這對我們夠用了。

ElysiaJS：Bun上的另一套玩法

性能敏感服務我們試過ElysiaJS，跑在Bun上。它給了Hono不一樣的東西。

ElysiaJS深度綁定Bun運行時，把性能榨得更干。但代價是鎖定——離開Bun，這套代碼跑不動。

我們的判斷：ElysiaJS適合明確知道"我就要Bun"的場景。如果還在Lambda和Bun之間搖擺，或者需要邊緣部署，Hono的通用性是更穩(wěn)妥的賭注。

兩個框架都生產(chǎn)跑了，沒有絕對優(yōu)劣，只有場景匹配。

NestJS：什么時候還值得選

NestJS沒被我們拋棄。Vendure還在用，大型電商系統(tǒng)底層還是它。

需要嚴格架構(gòu)規(guī)范、復雜依賴注入、大型團隊協(xié)作、長期維護的企業(yè)級系統(tǒng)，NestJS的裝飾器+模塊系統(tǒng)是有價值的。它強制的一致性，在代碼量上去之后能省很多事。

但新項目15個端點，這些就成了負擔。啟動時間、部署體積、運行時選擇——每一項都在提醒：工具要和任務匹配。

我們的選擇邏輯

現(xiàn)在新項目決策很快：

? 要跨運行時部署 → Hono

? 明確綁死Bun且極致性能 → ElysiaJS

? 大型企業(yè)系統(tǒng)、嚴格架構(gòu)規(guī)范 → NestJS

沒有框架能通吃。關(guān)鍵是誠實評估：這次我真的需要那些功能嗎？還是只是習慣了？

我們團隊的習慣正在被打破。冷啟動從5秒變100毫秒，同一套代碼在三個云平臺跑，TypeScript類型從服務端直通客戶端——這些體驗一旦有過，就很難假裝沒發(fā)生過。

最后說句得罪人的話：很多人選NestJS不是因為需要，是因為熟悉。熟悉不是需求，是慣性。慣性是要花錢的，冷啟動的每一秒都是賬單。