next-intl vs react-i18next vs Lingui：2026 年该选哪个

Next.js App Router 项目用 next-intl；React SPA，或者以后可能脱离单一框架的项目，用 react-i18next；如果你更看重编译期提取和精简 bundle，而不是生态规模，用 Lingui。这三者都是运行时 i18n 库：它们负责把翻译提供给组件，但都不会替你生成翻译键或语言文件。globalize.now 是 AI 驱动的本地化基础设施，能从代码库生成这些翻译键和目录，并且兼容这三个库。

这三个库到底做什么？

它们解决的是同一个运行时问题：给定键和 locale，返回正确的字符串，并处理好复数和格式化。这包括插值、日期和数字格式化，以及通过 ICU 风格消息实现的复数规则。

它们都不负责生成翻译。运行时库只消费已经存在的目录。找出组件中每一处用户可见的字符串，替换成翻译键，再为每种语言填充语言文件，这些工作仍然要有人来做。这是技术栈中独立的一层。把两层分清楚，是理解这场对比最快的办法：运行时库你只会选一个，它和填充目录的工具并不构成竞争。我们的开发者文档对这种分层有更详细的说明。

什么时候该用 next-intl？

当你使用 Next.js App Router 时。三个库里只有 next-intl 是围绕 App Router 的原语设计的：异步 Server Components、支持 locale 的导航与路由辅助函数，以及 metadata API。截至 2026 年 9 月，它的当前版本为 v4，npm 周下载量约 500 万，实际上已是新 Next.js 项目的默认选择，而不只是理论上的推荐。

消息采用 ICU MessageFormat，因此复数、性别和插值遵循业界通行的同一套标准。如果你不熟悉 ICU 语法，可以看我们写的ICU MessageFormat 通俗指南。代价是耦合：next-intl 是 Next.js 专用库，一旦离开 Next.js，你的 i18n 层也得跟着迁移。

什么时候该用 react-i18next？

当你没有使用 Next.js，或者想要最大的生态支持时。react-i18next 是 i18next 的 React 绑定，npm 周下载量约 1400 万，是使用最广的 React i18n 库，优势明显。i18next 核心已维护十多年，几乎所有需求都有对应插件：通过 HTTP 加载目录的 backend、语言检测器、缓存层，以及 React 之外的框架绑定。

大多数 AI 编程工具默认会选这个库。让 Cursor 或 Lovable 给 Vite + React 应用“添加翻译”，你几乎总会得到 i18next 的配置。这个默认选择合情合理：它到处都能用，其 JSON 目录格式也是生态里最接近通用语的格式。代价是它早于 Server Components 出现，所以在 App Router 上比 next-intl 需要更多接线，而且除非你另行安排，大部分翻译工作都在客户端完成。

什么情况下 Lingui 才是正确选择？

当 bundle 体积和源码书写体验是你的首要考虑时。截至 2026 年 9 月，Lingui 的主版本为 v6，走编译器优先路线：你用宏直接在代码里内联编写消息，CLI 在构建时把它们提取到目录中。编译后的目录没有运行时解析开销，因此 i18n 在 bundle 中的体积很小。

Lingui 还统一使用 gettext PO 文件作为目录格式，专业译员已经用了几十年。它的周下载量约 150 万，比 react-i18next 低一个数量级，所以 Stack Overflow 上的答案和第三方插件都会少一些。它适用于一般的 React 项目，不限于 Next.js，但和 react-i18next 一样，没有像 next-intl 那样围绕 App Router 原语来设计。

三者对比一览

AI 生成的代码库该选哪个？

还是按框架选，和前面一样——但要知道，AI 构建的应用出问题并不在库的选择上。无论装了哪个 i18n 库，Cursor、Claude Code 和 Lovable 默认都会生成硬编码的英文字符串，而且在你配置好库之后，Agent 修改组件时还会继续往里加。

所以正确的顺序是：先选框架对应的运行时库，再把提取字符串和维护目录当作独立问题来解决。Next.js 的完整配置流程，我们在给 Cursor 构建的 Next.js 应用添加 i18n里有详细记录；Next.js 集成页则介绍了 globalize.now 如何在任何运行时接线之前，为 next-intl 准备好翻译键和语言文件。

有了运行时库，还需要本地化基础设施吗？

需要，因为运行时库只负责读取目录，真正耗时间的是生成和维护目录。globalize.now 就处在这一层：连接仓库后，它会一次性转换整个代码库，把硬编码字符串替换为翻译键，并生成语言文件。完成这次一次性转换后，推送任务会翻译你后续提交中新增的目录条目。

输出格式为 JSON 或 PO——next-intl 和 i18next 用 JSON，Lingui 的原生格式用 PO——目录会直接落成运行时库已在使用的格式。如果你的应用已有部分 i18n 配置，同样可以处理：globalize.now 与现有 i18n 配合使用，而不是将其替换。套餐与用量费率见定价页。

这三个库没有哪个是错的选择。用 App Router 就选 next-intl，想要最大生态就选 react-i18next，想要编译期提取和 PO 目录就选 Lingui。选定一个，把字符串从组件里剥离出去，剩下的交给目录层。