Meteor.js 在 2026 年还有价值吗?

答案是肯定的:Meteor.js 仍在积极维护中。根据官方变更日志,3.5.2 版本已于 2026 年 9 月 4 日发布。

如果你上次接触 Meteor 还是几年前,这可能会让你有些意外。那个建立在 Fibers、Blaze 模板和自研 Babel 时代打包器之上的框架已经被彻底替换,而在你给 Meteor 判死刑之前,或者在你决定如何处理手头那个 2.x 应用之前,值得先了解一下取代它的到底是什么。

本文将介绍 Meteor 最初的设计目标、你为何逐渐不再听到它的消息、2024 至 2026 年间究竟发生了哪些变化,以及现在谁适合、谁不适合使用它。

Meteor.js 还有人用吗?先看证据

这个框架的发布节奏是稳定的。变更日志记录了 3.x 系列的 18 个版本,从 2024 年 7 月的 3.0 到 3.5.2;在此之前,2.x 系列从 2021 年 1 月到 2024 年 5 月发布了 17 个次要版本。如果你想自己去核实,有个细节值得注意:meteor/meteor 仓库并不发布 GitHub Releases,所以 releases 标签页看起来是空的。权威记录是变更日志,而非 GitHub。

生产环境用户依然存在,文档保持更新,核心团队每个版本都会合并社区的 PR。但这些是否足以让 Meteor 成为一个好选择,是另一个问题——本文余下部分将回答它。

Meteor 当初是为什么而生的?

自 2012 年发布以来,Meteor 的设计前提就是:一个实时应用根本不应该需要 API 层。一种语言贯穿客户端、服务端和数据库查询。服务端通过 Meteor 的 WebSocket 协议 DDP 发布 MongoDB 游标,客户端则将结果缓存在 MiniMongo 中——这是 Mongo 查询接口的一个内存版重新实现。当服务端数据发生变化时,已连接的客户端会自动更新。不需要 REST 端点,不需要 GraphQL resolver,也不需要状态同步代码。

围绕这个核心,Meteor 打包了小团队所需的其他一切:MongoDB 集成、带 OAuth 提供商的完整账户系统、零配置构建工具,以及一条命令完成部署。在 2012 到 2017 年间,这套组合确实是 JavaScript 世界里交付实时应用最快的方式,这也是它当年赢得如此多人心和黑客松的原因。

你为什么不再听到 Meteor 的消息了?

“React 赢了”只是三分之一的原因。Blaze,Meteor 自家的模板层,输给了 React 并再未追上,但更深的创伤在于组织层面。2016 年前后,Meteor Development Group 将注意力转向了 Apollo 和 GraphQL,框架明显不再是公司的优先事项。免费的 meteor.com 托管服务消失了。社区中的知名人物纷纷离开,教程逐渐过时,Atmosphere 上的包被弃置。

接着是决定性的一环:对那个移除 Fibers 的版本的漫长等待。Fibers 是让 Meteor 服务端代码看起来像同步代码的协程库,它阻碍了 Node 版本升级,也让 Meteor 与其他所有 Node 代码库的工作方式渐行渐远。早在 Tiny 于 2019 年 10 月接手 Meteor 之前,移除 Fibers 就已讨论多年,而 Meteor 3.0 直到 2024 年年中才发布。大部分社区已经不愿再等。品牌的消亡比技术本身快得多,而技术却在沉寂中持续进步。

从 Meteor 3.0 到 3.5 发生了什么变化?

Meteor 3.0 于 2024 年 7 月 15 日发布,彻底移除了 Fibers,转向原生 async/await,并将 HTTP 层从 Connect 换成了 Express。根据变更日志,此后的各个版本遵循同一条主线:

这条贯穿线比表中任何单独一行都更重要:Meteor 不再是一个自成一体的定制运行时,而变成了一个普通的 Node.js 应用。用 async/await 取代 Fibers,用 Express 取代 Connect,用 SWC 和 Rspack 取代定制的 Babel 流水线,用 Change Streams 取代 oplog tailing。Change Streams 确实有一个门槛:你的数据库必须是 MongoDB 6 或更高版本,且以副本集或分片集群方式运行。不满足条件时,Meteor 会自行回退到 oplog tailing 或轮询。正是这种”常规化”,才让重新评估这个框架变得有意义。

对于 2.x 代码,迁移在形式上是机械化的:同步集合调用变为对应的异步版本。

// Meteor 2.x
const doc = Tasks.findOne(taskId);
Tasks.insert({ text: "hello" });

// Meteor 3.x
const doc = await Tasks.findOneAsync(taskId);
await Tasks.insertAsync({ text: "hello" });

关于性能:Meteor 官方在其 Galaxy Cloud 应用上测得的构建数据显示,使用 SWC 后构建速度提升约 60%,使用 Rspack 后构建速度提升 3.5 倍以上,客户端包体积最多缩小 88%。Meteor 团队在一个 Galaxy 容器上单独进行的压力测试则显示,Change Streams 下的并发连接承载能力比 oplog 高出 40%。这些应当视为厂商自测的基准数据。

“有维护”不等于”生态健康”

“Meteor 是否在维护”和”它的生态是否健康”是两个不同的问题,答案也不同。框架在持续发布;围绕它的生态却依然单薄。人才池很小,而且已经萎缩了十年。Atmosphere,Meteor 的包注册中心,规模只是主流 npm 的一小部分,而且很多你想用的包都是社区维护的、原项目已弃置的分支。数据层在设计上就以 MongoDB 为中心,所以如果你的数据是关系型的,你就是在跟框架对着干。

更大的问题在于适配度。Meteor 的核心优势——通过 socket 向已连接客户端推送实时数据——恰恰不是大多数团队正在优化的目标。Node 领域的很大一部分工作是服务端渲染、以 SEO 为导向、内容密集型的站点,而 Meteor 并不适合这类任务。如果你的成功指标涉及 Googlebot,请选择为此而生的工具。

2026 年你该用 Meteor.js 吗?

2026 年的 Meteor 有人维护、已完成现代化改造,并且对于特定一类任务是合理的选择:实时优先的应用,例如仪表盘、聊天和协作工具;内部工具——在这类场景中,统一语言、无 API 层的优势胜过生态规模;以及快速原型开发。如果你手上有 2.x 应用,升级到 3.x 的路径是切实可行的,官方迁移指南中有完整文档,值得着手去做,而不是任由应用烂在一个已停止支持的运行时上。Meteor 不是一个通用的默认选项,把它用在内容站点或面向公众的 SEO 项目上会是个错误。自己去看变更日志,如果实时场景确实契合,就用 npx meteor 跑一个原型试试,然后基于它现在的样子而非你记忆中的样子来做决定。

常见问题

我可以在 Meteor 中使用 MongoDB 以外的数据库吗?

可以,但你会失去框架的主要优势。Meteor 的响应式技术栈(publications、MiniMongo 和 Change Streams 驱动)只支持 MongoDB,内置的账户系统也把用户数据存在那里。像 PostgreSQL 这样的数据库可以通过标准 npm 驱动在 Meteor methods 内部使用,但你得自己编写数据加载代码,并且得不到实时查询能力。如果你的数据从第一天起就是关系型的,请选择另一个框架。

Meteor 3 必须用 Blaze 吗,还是可以用 React、Vue 或 Svelte?

Meteor 与视图层无关。运行 meteor create 默认会生成一个 React 应用,同时官方也提供了 Vue、Svelte、Solid 和 Blaze 的脚手架模板。Meteor 提供构建系统、DDP 数据层和账户系统,由你选择的库负责渲染 UI。Blaze 仍然可用,并由社区继续维护,但当前大多数文档、脚手架和包活跃度都以 React 为前提。

我可以把 Meteor 2.x 应用直接升级到 3.x 吗,还是需要中间步骤?

推荐的路径是从 2.x 开始。异步集合方法(findOneAsync、insertAsync 等)在 Meteor 2.8 中就已引入,因此你可以在仍运行 2.x 的情况下逐步改造服务端代码,等到没有任何代码依赖 Fibers 式同步调用后再跳到 3.x。第三方 Atmosphere 包通常是主要阻碍:你的应用用到的每一个包,都必须先发布兼容 3.x 的版本,你才能切换。

部署 Meteor 应用必须用 Galaxy 吗?

不必。运行 meteor build 会产出一个标准的 Node.js 应用,你可以把它跑在任何提供 Node 和 MongoDB 连接的主机上:VPS、Docker 或云服务商都可以。Galaxy 是 Meteor Software 提供的可选托管服务。在 3.5 上有一个部署细节值得注意:要获得 Change Streams 响应式能力,你的 MongoDB 必须是 6 或更高版本,并配置为副本集或分片集群。否则 Meteor 会自行回退到 oplog tailing 或轮询,无需你做任何配置。