Node.js框架的江湖：为什么Fastify实力在线，却始终火不起来？

Node.js框架的江湖：为什么Fastify实力在线，却始终火不起来？

最近在技术社区闲逛，看到有人在Hacker News上发帖问：”Fastify为什么一直没火起来？”这个问题瞬间击中了我。作为一个常年折腾各种技术栈、也帮不少朋友做过技术选型的人，我太理解这种”明明是好东西，怎么就没人用”的困惑了。

说实话，Fastify在Node.js圈子里口碑一直不错，性能强悍、插件生态完善、背后还有大神Matteo Collina坐镇。但现实是，你在招聘网站上搜Node.js开发，十个JD里有八个写的是Express，剩下两个写NestJS。在技术社区里，讨论Hono、Elysia这些新秀的帖子热度明显更高。这背后到底藏着什么逻辑？今天咱们就掰开揉碎聊聊这件事，顺便从中挖点对普通开发者、甚至对做副业有兴趣的朋友有价值的思考。

先搞清楚Fastify到底强在哪

咱们先把Fastify的家底盘一盘。这框架从2016年诞生到现在快十年了，核心卖点就一个字——快。官方基准测试里，它的请求处理能力比Express高出好几倍，内存占用也更低。原因在于它用了JSON Schema来校验请求和响应，在序列化这块下了狠功夫，减少了大量不必要的CPU开销。

除了性能，Fastify的插件系统也设计得很干净。它把所有功能都拆成插件，每个插件有独立的上下文，不会像Express那样中间件互相污染。这让大型项目的代码组织变得非常清爽。而且它原生支持TypeScript，对现代开发流程友好。

更重要的是，Matteo Collina这位老兄在Node.js社区的地位极高，他是Node.js核心代码贡献者，也是pino、undici等知名库的作者。按理说，有这种大神背书，Fastify的资源应该不愁。可现实就是这么打脸——技术好人脉广，不代表产品就能火。

“先发优势”是道跨不过去的坎

咱们得承认，Express在Node.js框架里的地位，有点像Java里的Spring，Python里的Django——它赢在时间点上。2010年Express诞生的时候，Node.js刚火起来，那时候的开发者没得选，Express就是默认答案。十年下来，网上教程、开源项目、公司内部代码库，全是Express的影子。

Fastify出生晚了整整六年。六年时间，足够一个技术生态沉淀出海量的存量代码。你去看GitHub上任何一个Node.js老项目，几乎都是Express写的。对于企业来说，新项目用Fastify可能还行，但老项目迁移成本太高，没人愿意冒这个险。

还有一个很现实的问题：招聘。技术负责人做选型的时候，得考虑团队能不能快速上手。Express的开发者一抓一大把，招人容易；Fastify呢，虽然学习曲线不陡，但简历上写熟悉Fastify的候选人少得可怜。为了一个性能提升去增加招人难度，大多数CTO都会觉得不划算。

Hono们凭什么能后来居上？

那有人要问了：既然Fastify都没能撼动Express，凭什么Hono这个2022年才出现的框架，能在短短两三年里混得风生水起？这就得聊聊技术趋势的变化了。

Hono的定位非常清晰——为边缘计算而生。它体积极小，能跑在Cloudflare Workers、Deno Deploy这些serverless环境里。而这两年AI应用爆发，很多AI Agent框架、检索增强生成（RAG）工具都需要在边缘节点快速响应，Hono天然契合这个场景。你去看LangChain、Vercel AI SDK这些库的文档，默认的Node.js框架示例很多都用了Hono。

再加上Hono的API设计非常现代化，吸收了Web标准里Request/Response对象，写起来和React的fetch风格一致，前端开发者上手零成本。这种”踩在时代节拍上”的优势，是Fastify这种偏传统Node.js生态的框架没法比的。

说白了，Fastify是在和Express抢存量市场，而Hono是在开辟增量市场。增量市场的用户没有历史包袱，谁好用用谁，自然更容易形成口碑传播。

性能不是一切，生态才是护城河

很多技术人容易犯一个毛病：把性能当成技术选型的唯一标准。但真实世界里，绝大多数应用根本到不了性能瓶颈那一步。一个每天几千请求的小工具，你用Express还是Fastify，差别微乎其微；但如果你需要集成支付、日志、数据库ORM、认证中间件，生态的丰富程度才是决定开发效率的关键。

Express的npm周下载量超过2500万，周边中间件多到数不清。Fastify虽然插件也不少，但很多都是Matteo自己团队维护的，第三方贡献的活跃度明显不如Express。说白了，大生态意味着你遇到任何问题，都能在Stack Overflow上找到答案；而小生态，遇到坑只能自己踩。

这让我想起一个副业项目里常见的误区：很多人做独立站的时候，非要追求最先进的框架、最炫的技术，结果光折腾环境就花了一周，业务反而没推进。其实对于大多数个人项目、小团队来说，稳定、熟悉、有人维护的技术栈，远比”看起来高级”重要得多。技术选型如此，做网站选平台也一样——与其纠结用哪个冷门框架，不如先把站搭起来跑通业务。想做这类副业，第一步是建一个自己的网站。Hostinger支持支付宝付款，$2.99/月，新手建站首选。

“权威背书”为什么没起作用？

咱们再说回Matteo Collina。按理说，有Node.js核心贡献者站台，Fastify应该不缺曝光度。但仔细想想，技术圈子里”大神光环”的边际效应其实很有限。Matteo的号召力主要影响的是那些深度关注Node.js底层开发的工程师，而这部分人在整个开发者群体里占比太小了。

反过来看，Hono的走红更多靠的是社区自下而上的传播。它在X上、Reddit上被很多独立开发者自发推荐，因为大家发现这玩意儿写起来太爽了，然后一传十十传百。这种”用户自发安利”的力量，比任何权威背书都强大。

这其实给咱们做内容、做产品的人提了个醒：与其花精力找大佬站台，不如把一个核心体验做到极致，让用户自己愿意帮你传播。Fastify的问题在于，它的”好”需要深度使用后才能体会，而Hono的”好”是上手五分钟就能感受到的——开发体验上的差异，决定了口碑传播的速度。

从Fastify的”不火”，我们能学到什么？

聊了这么多，咱们不妨跳出技术本身，从这件事里提炼点通用的道理。无论你是做技术选型、做产品、还是搞副业，这几点都值得琢磨：

• 时机比实力更重要：Fastify性能再强，错过了Express称霸的那个窗口期，就很难翻盘。做副业也一样，红海市场里你再优秀，也抵不过蓝海市场里普普通通的先行者。
• 生态比单点能力重要：一个工具的价值，很大程度上取决于它周围有多少配套工具。做独立站的时候，选一个插件丰富、文档齐全的建站平台，比选择一个功能强大但生态贫瘠的冷门平台要明智得多。
• 开发体验决定传播速度：Hono能火，是因为它让写代码变成一件愉快的事。同样，如果你的产品能让用户第一次使用就感到惊艳，那它就有机会被主动推荐。
• 不要迷信权威：Matteo的背书没有让Fastify成为主流，这说明技术圈子的口碑传播是去中心化的。做内容的时候，与其花钱找大V背书，不如花心思服务好你的早期用户。

给Fastify用户的现实建议

当然，我说这么多不是让大家放弃Fastify。如果你已经在用Fastify，而且项目跑得好好的，完全没必要因为”不火”就换框架。技术选型没有绝对的对错，只有适不适合。Fastify在性能敏感的场景、或者你深度依赖JSON Schema校验的项目里，依然是很好的选择。

但如果你在做一个新的Node.js项目，而且不是那种极端性能导向的应用，我建议你认真评估一下Hono或者Express。不是说Fastify不好，而是选一个社区活跃度更高、招聘更容易、教程更丰富的框架，长期来看省心的多。尤其是你打算做开源项目或者接外包，用主流框架意味着你更容易找到协作者，也更容易让客户信任。

另外，如果你对边缘计算、serverless、AI应用开发这些方向感兴趣，那Hono几乎是绕不开的选择。它和Cloudflare Workers、Bun这些新一代运行时配合得天衣无缝，未来几年这个赛道只会越来越热。

写在最后：火不火，真的重要吗？

回到最开始的问题：Fastify为什么没火？其实答案已经不重要了。重要的是，这件事让我们看到技术圈的复杂性——一款产品的成败，技术实力只占一小部分，时机、生态、传播路径、用户心理，每一个因素都比代码本身更影响命运。

对于咱们普通开发者来说，与其纠结”哪个框架最火”，不如想清楚”哪个框架最适合我的场景”。同样的道理也适用于副业和建站：别追求什么最前沿的技术，先把手头的事情跑通，用最顺手、社区支持最成熟的方案，把时间和精力花在业务逻辑和用户需求上，这才是能真正让你赚钱的路线。

如果你看完这篇文章，对技术选型、建站副业有想聊的，欢迎在评论区留言。我一直在关注独立开发、出海建站这些话题，也踩过不少坑，咱们可以一起交流交流。

---

📖 相关阅读

• 拼多多无货源，单店月入5000+，我是怎么一步步跑通的
• 大学生暑假用建站赚了学费，赚的钱比打工多3倍
• 别急着辞职，先把“轻资产+睡后收入”这六个字嚼碎了再动手
• 程序员辞职做独立站，6个月收入超过原来工资