react-Intl VS react-i18next VS intlayer | React 国际化 (i18n)

本指南比较了三种成熟的 React 国际化方案：react-intl（FormatJS）、react-i18next（i18next）和 Intlayer。我们重点关注 纯 React 应用（例如 Vite、CRA、SPA）。如果您使用的是 Next.js，请参阅我们专门的 Next.js 比较。

我们将评估：

架构与内容组织
TypeScript 与安全性
缺失翻译的处理
丰富的内容与格式化能力
性能与加载行为
开发者体验（DX）、工具链与维护
SEO/路由（依赖框架）

简而言之：这三者都能实现 React 应用的本地化。如果您需要组件范围的内容、严格的 TypeScript 类型、构建时缺失键检查、支持 Tree-shaking 的字典，以及内置的编辑工具（可视化编辑器/CMS + 可选的 AI 翻译），那么 Intlayer 是模块化 React 代码库中最完整的选择。

高层定位

react-intl - 以 ICU 为先，符合标准的格式化（日期/数字/复数），拥有成熟的 API。目录通常是集中管理的；键的安全性和构建时验证主要由你负责。
react-i18next - 极其流行且灵活；支持命名空间、检测器和许多插件（ICU、后端等）。功能强大，但随着项目规模扩大，配置可能变得复杂。
Intlayer - 面向组件的 React 内容模型，严格的 TS 类型，构建时检查，支持 Tree-shaking，以及 可视化编辑器/CMS 和 AI 辅助翻译。兼容 React Router、Vite、CRA 等。

功能矩阵（React 重点）

功能	react-intlayer (Intlayer)	react-i18next (i18next)	react-intl (FormatJS)
组件附近的翻译	✅ 是，内容与每个组件共置	❌ 否	❌ 否
TypeScript 集成	✅ 高级，自动生成严格类型	⚠️ 基础；需要额外配置以保证安全	✅ 良好，但不够严格
缺失翻译检测	✅ TypeScript 错误高亮和构建时错误/警告	⚠️ 主要是运行时回退字符串	⚠️ 回退字符串
丰富内容（JSX/Markdown/组件）	✅ 直接支持	⚠️ 有限 / 仅插值	⚠️ ICU 语法，不是真正的 JSX
AI 驱动的翻译	✅ 是，支持多个 AI 提供商。可使用您自己的 API 密钥。考虑到您的应用程序和内容范围的上下文	❌ 否	❌ 否
可视化编辑器	✅ 是，本地可视化编辑器 + 可选 CMS；可以外部化代码库内容；可嵌入	❌ 否 / 通过外部本地化平台提供	❌ 否 / 通过外部本地化平台提供
本地化路由	✅ 是，开箱即用支持本地化路径（兼容 Next.js 和 Vite）	⚠️ 无内置支持，需要插件（例如 next-i18next）或自定义路由配置	❌ 否，仅支持消息格式化，路由需手动管理
动态路由生成	✅ 是	⚠️ 依赖插件/生态系统或手动设置	❌ 不提供
复数形式处理	✅ 基于枚举的模式	✅ 可配置（如 i18next-icu 插件）	✅ （ICU）
格式化（日期、数字、货币）	✅ 优化的格式化器（底层使用 Intl）	⚠️ 通过插件或自定义 Intl 使用	✅ ICU 格式化器
内容格式	✅ .tsx, .ts, .js, .json, .md, .txt, (.yaml 进行中)	⚠️ .json	✅ .json, .js
ICU 支持	⚠️ 进行中	⚠️ 通过插件（如 i18next-icu）	✅ 是
SEO 辅助工具（hreflang，网站地图）	✅ 内置工具：网站地图、robots.txt、元数据辅助工具	⚠️ 社区插件/手动	❌ 非核心功能
生态系统 / 社区	⚠️ 较小但增长迅速且反应灵敏	✅ 最大且成熟	✅ 大型
服务器端渲染与服务器组件	✅ 支持，针对 SSR / React 服务器组件进行了优化	⚠️ 支持页面级别，但需要在组件树上传递 t 函数给子服务器组件	❌ 不支持，需要在组件树上传递 t 函数给子服务器组件
Tree-shaking（仅加载使用的内容）	✅ 支持，通过 Babel/SWC 插件在构建时按组件进行优化	⚠️ 通常加载全部（可通过命名空间/代码拆分进行改进）	⚠️ 通常加载全部
懒加载	✅ 是的，按语言环境 / 按词典	✅ 是的（例如，按需加载后端/命名空间）	✅ 是的（拆分语言包）
清除未使用内容	✅ 是的，按词典在构建时	❌ 否，仅通过手动命名空间分割	❌ 否，所有声明的消息都会被打包
大型项目管理	✅ 鼓励模块化，适合设计系统	⚠️ 需要良好的文件管理	⚠️ 中央目录可能变得庞大

深度比较

1) 架构与可扩展性

react-intl / react-i18next：大多数配置保持每种语言的集中式本地化文件夹，有时按命名空间（i18next）拆分。早期效果良好，但随着应用增长，成为共享的表面区域。
Intlayer：提倡与其所服务的 UI 共置的 每组件（或每功能）字典。这保持了所有权的清晰，便于组件的复制/迁移，并减少跨团队的键变动。未使用的内容更容易识别和删除。

重要原因： 模块化内容反映模块化 UI。当翻译与其所属组件共存时，大型 React 代码库会保持更整洁。

2) TypeScript 与安全性

react-intl：类型定义扎实，但没有自动键类型；你需要自己强制安全模式。
react-i18next：为钩子提供强类型；严格的键类型通常需要额外配置或生成器。
Intlayer：从您的内容自动生成严格类型。IDE 自动完成和编译时错误可以在运行时之前捕获拼写错误和缺失的键。

重要原因： 将失败“左移”（到构建/CI阶段）可以减少生产环境问题并加快开发者反馈循环。

3) 缺失翻译处理

react-intl / react-i18next：默认使用运行时回退（键回显或默认语言）。您可以添加代码检查/插件，但构建时不保证检测。
Intlayer：通过构建时检测，在缺少必需的语言或键时发出警告或错误。

重要原因： CI 在缺失字符串时失败，防止“神秘的英文”泄漏到非英文界面中。

4) 丰富内容与格式化

react-intl：对复数、选择、日期/数字和消息组合提供出色的 ICU 支持。可以使用 JSX，但思维模型仍以消息为中心。
react-i18next：灵活的插值和用于嵌入元素/组件的 <Trans> 组件；通过插件支持 ICU。
Intlayer：内容文件可以包含 丰富节点（JSX/Markdown/组件）和 元数据。格式化底层使用 Intl；复数模式设计符合人体工学。

重要原因： 当库能够干净地支持 React 节点时，处理复杂的 UI 文本（链接、加粗部分、内联组件）会更加轻松。

5) 性能与加载行为

react-intl / react-i18next：您通常需要手动管理目录拆分和懒加载（命名空间/动态导入）。这种方式有效但需要严格的规范。
Intlayer：自动摇树优化未使用的字典，并开箱即用地支持按字典/按语言的懒加载。

重要性说明： 更小的包体积和更少的未使用字符串能提升启动和导航性能。

6) 开发体验（DX）、工具链与维护

react-intl / react-i18next：拥有广泛的社区生态系统；对于编辑工作流，通常采用外部本地化平台。
Intlayer：提供免费的可视化编辑器和可选的内容管理系统（CMS）（内容可保存在 Git 中或外部化）。还提供用于内容创作的VSCode 扩展，以及使用您自己的提供商密钥进行的AI 辅助翻译。

重要原因： 内置工具缩短了开发者与内容作者之间的反馈周期--减少了胶水代码，降低了对第三方依赖的需求。

何时选择哪种方案？

如果您需要以 ICU 为优先的消息格式化，且希望使用简洁、符合标准的 API，并且您的团队能够手动维护目录和安全检查，请选择 react-intl。
如果您需要i18next 生态系统的广泛支持（检测器、后端、ICU 插件、集成等），并且愿意接受更多配置以获得更高灵活性，请选择 react-i18next。
选择 Intlayer 如果你重视 组件范围的内容管理、严格的 TypeScript 类型检查、构建时保证、摇树优化，以及 开箱即用 的编辑工具 -- 尤其适用于 大型、模块化 的 React 应用。

实用迁移建议（react-intl / react-i18next → Intlayer）

渐进迁移：从一个功能或路由开始；在过渡期间并行保留旧版目录。
采用每组件字典：将内容与组件共置，减少耦合。
启用严格检查：让构建时错误提前暴露缺失的键/语言，便于 CI 早期发现。
测量包体积：预期未使用的字符串被剔除后包体积会减小。

结论

所有三个库都能有效地实现 React 的本地化。区别在于你需要构建多少基础设施，才能达到一个安全、可扩展的环境：

使用 Intlayer，模块化内容、严格的 TS 类型检查、构建时安全性、摇树优化的包以及编辑工具都是默认配置，而非额外负担。
如果你的团队重视多语言、组件驱动的 React 应用中的可维护性和速度，Intlayer 提供了目前最完整的开发者和内容工作流。

next-i18next vs next-intl vs Intlayer