Next.js 多语言对决：next-intl vs next-i18next vs Intlayer

在 Next.js 中加入多语言，往往会变成同时处理庞大的 JSON 词库、漏掉的 key，以及路由/SEO 粘合代码。下面是一份务实的、中等长度的速览，帮你快速做选择。

快速概览

next-intl: 最小化、直观。集中式词库，适合中小型应用的优秀开发体验。按路由/布局注入消息。
next-i18next: 为 Next.js 提供 i18next。生态成熟、插件丰富（如 ICU），但需要更多配置与维护。如果团队已熟悉 i18next 会更顺手。
Intlayer: 现代的、以组件为单位的内容模型，严格的 TypeScript 类型，构建时缺失键检查、可树摇的词典，App Router + SEO 助手，可选可视化编辑器/CMS 与 AI 翻译辅助。

谁该选哪一个

在规模化时真正重要的差异

内容模型: next-intl/next-i18next 倾向集中式；Intlayer 鼓励按组件划分词典，便于复用与清理。
类型安全: Intlayer 从内容生成严格类型；其他方案也不错/基础，但更多依赖你的实践约束。
缺失翻译: next-intl / next-i18next 在运行时处理；Intlayer 在构建时直接标记。
打包与加载: 三者都可按语言/路由拆分。Intlayer 的构建期分析可对未用词典进行树摇，并预解析回退。
RSC 与开发体验: 三者都支持 App Router。Intlayer 通过服务端安全的 hooks/providers 减少样板，并内置 SEO 助手（hreflang、sitemap、robots）。
TMS 集成: next-intl/next-i18next 更契合传统集中式 JSON 流程。Intlayer 提供替代方案（可视化编辑器/CMS、AI 协助），并在持续增加集成。

结论

三者都能做好本地化。关键在于你愿意维护多少"管线"。如果你重视模块化内容、严格的 TS 类型，以及面向现代 Next.js 的构建期保障，今天 Intlayer 提供的体验最完整。

但如果你想要面对大型项目的久经考验的标准方案，i18next 依然是行业常用标准，并能与各类本地化平台对接。