2026 年，vue-i18n 已经过时了吗？

在 Vue 生态系统中，鲜有库能达到 vue-i18n 的普及度。自 Vue 2 时代起由 Kazupon 持续维护，它支撑着 @nuxtjs/i18n，几乎是多语言 Vue 应用的默认首选。

然而，2026 年的基准测试得出了一个出人意料的数据：在所有测试的前端框架中，vue-i18n 竟是最庞大的本地化运行时。

在基于 Vite + Vue 搭建的仅 31.5 KB 的空白初始项目中，引入 vue-i18n 后，单页平均 JavaScript 体积飙升至 136.4 KB，翻了 4 倍有余。

为什么一个以轻量、灵动著称的框架，其配套的国际化工具却如此厚重？其纯运行时的传统模型在今天是否依然合理？

核心观点

测试中体积最大的运行时：

在未载入任何翻译内容前，其基础体积即达 24.3 KB（gzip 压缩后，未压缩约 83.2 KB），约是 intlayer 核心运行时（2.7 KB）的 9 倍。

单页开销增加 330%：

vue-i18n 让一个基础 Vue 页面从 31.5 KB 暴增至 136.4 KB。相比之下，Intlayer 仅为 59.3 KB，单页体积减少了 56%。

浏览器里附带编译器：

除非在打包配置中显式设置别名，否则 vue-i18n 默认会把一个功能完整的消息格式编译器打包进浏览器，用于在客户端实时解析文本。

维护节奏趋于平缓：

在过去的 12 个月里，vue-i18n 提交了约 259 次 commit，工作重心主要落在常规 Bug 修复与 Vue 新版本的被动兼容。

缺乏现代原生工具链：

缺乏官方提供的 Language Server (LSP)、面向 AI 的 MCP Server 或基于 CLI 的全自动化翻译支持。

维护模式 vs. 现代工具生态

显示表格的所有内容

显示表格的所有内容

在弹窗中打开表格以清晰地查看所有数据

仓库	Stars	总 Commit 数	年 Commit 数	最近一次 Commit
intlify/vue-i18n
aymericzip/intlayer

过去一年的产出：

• intlify/vue-i18n：259 次 commit（Vue 3 与 Nuxt 的例行维护）。
• aymericzip/intlayer：4,343 次 commit（持续投入编译器优化、LSP 语言服务以及深度 AI 集成）。

久经考验的库往往代表稳定，但现代化前端开发已全面转向构建期 AST 转换、无用代码精简和 AI 赋能。受制于纯运行时的架构设计，旧模型较难自如融入这些革新。

基于 Vite + Vue 的实测数据

针对包含 10 个页面、10 种语言的 Vite + Vue 3 应用进行测试：

在真实浏览器中开启 gzip 压缩环境下测试。完整数据见 Vue 基准测试文档。

库本身的基础体积

未引入任何翻译文本时客户端的空白开销：

仅 vue-i18n 运行时的体积就达到 24.3 KB（gzip 压缩后），几乎相当于整个 Vue 核心库的大小。而 Intlayer 仅增加 2.7 KB。

页面体积与数据泄漏分析

核心观察

比例增幅极其明显：

由于 Vue 基础框架非常小巧（约 31 KB），引入 vue-i18n 会使页面总体积直接跃升四倍多。

严重的跨路由文本泄漏：

在默认模式下，单个路由接收到的翻译内容中有 90% 实际上属于其他页面。Intlayer 通过静态剔除将该数据降低至 0.0%。

独立作用域组件体积过大：

由于词典数据在各个作用域中被重复复制，使用 vue-i18n 的局部组件平均体积高达 196 KB，而在 Intlayer 中仅为 6.5 KB。

为什么 vue-i18n 如此沉重？

打包进浏览器的 AST 编译器

vue-i18n 内置了完整的消息格式编译器。复杂的复数规则、变量插值在客户端运行期间实时被转译成抽象语法树（AST）。

要规避这一开销，开发者必须手动在打包器中为 vue-i18n/dist/vue-i18n.runtime.esm-bundler.js 配置别名，并借助 @intlify/unplugin-vue-i18n 实施预编译。但在实际工程中，这一步骤经常被遗漏。

单体式功能捆绑

vue-i18n 集成了日期和数字格式化工具、链式消息、传统 Options API 兼容垫片（$t、v-t）以及响应式 Proxy 逻辑。即便你的组件只是在 <script setup> 中读取普通字符串，也必须全盘加载。

动态键名阻断 Tree-shaking

由于 "home.hero.title" 在运行时动态求值，打包工具无法静态推测被使用的文本范围。多余的翻译内容不得不全部存留在包内。

<script setup>
import { useI18n } from "vue-i18n";

const { t } = useI18n();
</script>

<template>
  <h1>{{ t("home.hero.title") }}</h1>
</template>

<script setup>
import { useIntlayer } from "vue-intlayer";

const { title } = useIntlayer("hero");
</script>

<template>
  <h1>{{ title }}</h1>
</template>

Intlayer 编译器能够准确识别访问了哪些属性，在生成客户端 bundle 之前剔除无用字段。具体解析请查阅打包优化。

开发者体验对比

分离式 JSON vs. 组件就近组织

在 vue-i18n 中，翻译通常放在独立的 locales/ 文件夹中。Intlayer 则支持把内容声明直接放置在组件文件同级：

{
  "hero": {
    "title": "Ship in every language"
  }
}

{
  "hero": {
    "title": "用每一种语言发布产品"
  }
}

<script setup>
import { useI18n } from "vue-i18n";

const { t } = useI18n();
</script>

<template>
  <h1>{{ t("hero.title") }}</h1>
</template>

import { t, type Dictionary } from "intlayer";

export default {
  key: "hero",
  content: {
    title: t({
      en: "Ship in every language",
      zh: "用每一种语言发布产品",
    }),
  },
} satisfies Dictionary;

<script setup>
import { useIntlayer } from "vue-intlayer";

const { title } = useIntlayer("hero");
</script>

<template>
  <h1>{{ title }}</h1>
</template>

移动或删除 Hero.vue 时，与其绑定的多语言声明文件也会一并同步处理。

代码提示 vs. 严格完备性检查

DefineLocaleMessage 能带来基于基准模式的代码补全，但无法验证多语言翻译的完备性。即使 zh.json 中遗漏了键，TypeScript 也不会阻止编译。

在 Intlayer 中，多语言数据遵循严格校验机制。开启 strictMode 后，只要任意语言存在未翻译词条，构建流程便会即刻报错中断。

IDE 与 AI 辅助工具

翻译流水线

vue-i18n 没有提供内置的翻译命令。开发者通常必须将文件导出给第三方平台（如 Crowdin 或 Phrase）。

Intlayer 提供了开箱即用的闭环工作流：

本地 AI 自动补全（intlayer fill）：

直接配合个人的 OpenAI、Anthropic、Mistral 或 Gemini API 密钥，自动补齐缺失词条。

自主托管的可视化 CMS：

集成 Intlayer CMS，方便非技术人员直观修改文案，并直接以 Git 提交的形式落盘。

开源宽松授权：

全套组件均基于 Apache 2.0 协议发布。

什么时候选用 vue-i18n 依然合适？

如何改进我现有的 vue-i18n 配置？

Intlayer 提供了平滑替换的兼容包，完整再现了 vue-i18n 与 @nuxtjs/i18n 的核心函数签名（useI18n、$t、<i18n-t>）。你无需重构模板或组合式函数（composables），即可无缝过渡到基于编译器的轻量级架构。

只需运行单条命令即可完成集成：

npx intlayer init --interactive

该交互式 CLI 工具会自动完成以下工作：

1. 安装 @intlayer/vue-i18n 或 @intlayer/nuxt-i18n 兼容包。
2. 配置 Vite 或 Nuxt 打包别名（alias），使现有的导入语句和模板用法平滑路由至 Intlayer，之后便可直接从 package.json 中移除 vue-i18n。
3. 立即激活语言服务器（LSP）诊断，从客户端包中剥离 24 KB 的运行时 AST 解析器，并开启本地 AI 自动化翻译流程，无需繁杂的工程重构。

更多详细步骤请参考我们的专题文档：

• 平滑兼容层： 使用 vue-i18n 兼容层 或 @nuxtjs/i18n 兼容层，即可在保留旧有模板语法的同时享受现代构建优化。
• 迁移指南参考： 查阅迁移手册逐步将 JSON 转换为类型安全的字典配置：从 vue-i18n 迁移、从 @nuxtjs/i18n 迁移。
• 混合使用方案： 你也可以在运行时维持 vue-i18n，仅将 Intlayer 与 vue-i18n 搭配使用，以低成本引入严格类型检查和本地 AI 翻译。

使用免费的 i18n SEO 分析器 测量你当前应用的实际打包体积和内容泄漏情况：

相关阅读

• Vue & Vite i18n 性能评测：深度对比报告
• vue-i18n 与 Intlayer 全方位对比
• 2026 年，next-intl 已经过时了吗？
• 编译型国际化与声明式架构优势剖析