多语言项目中应通过静态分析提取引用的 locale 并结合白名单过滤语言包，而非简单删除；需保留 fallback 语言、运行时兜底，并在 CI 中验证功能与体积。

在多语言项目中，未使用的语言包常占大量体积，尤其当支持十几种语言时。自定义构建流程能精准剔除无引用的语言资源，显著减小最终包体——关键在于“按需加载”和“引用分析”双结合，而非简单删除文件。

识别哪些语言包实际被引用

静态分析源码中的语言标识（如 zh-CN、en-US）是前提。常见方式包括：

• 扫描所有 i18n.locale、useI18n({ locale: 'xx' }) 或类似调用，提取硬编码的 locale 字符串
• 检查配置对象（如 createI18n({ legacy: false, locale: 'en' })）中初始化的默认语言
• 若使用动态 locale 切换（如从 URL 参数或 localStorage 读取），需显式声明白名单，避免误删

在构建前过滤语言资源文件

以 Vue + vue-i18n + Vite 为例，可在 vite.config.ts 的 build.rollupOptions.plugins 中插入自定义插件：

• 读取 src/locales/**/*.{json,yaml,js}，解析文件名或路径推断 locale（如 zh-CN.json → zh-CN）
• 比对上一步提取出的“已引用 locale 列表”，仅保留匹配项
• 将过滤后的语言包注入打包上下文（例如重写 import { zhCN } from '@/locales' 为只含有效模块）

注意：JSON/YAML 文件需转为 ESM 模块再处理，避免运行时解析开销。

配合运行时语言检测做兜底

纯构建期剔除存在风险——比如用户手动修改 URL 中的 locale 参数，或后端下发未知语言码。建议：

• 构建产物中保留一个最小化 fallback 语言包（如 en.json），并在运行时捕获 missing key 错误
• 用 fallbackLocale: 'en' 配合 missing 回调，记录未命中语言并上报，辅助后续白名单优化
• 不推荐在构建时完全禁用 fallback，而是让其轻量、可追溯

验证与持续维护

剔除后必须验证两点：一是页面语言切换功能是否完整，二是构建体积变化是否符合预期。可：

• 在 CI 中加入体积断言（如 gzip 大小 ），防止新增语言包未同步更新白名单
• 生成一份 locale-coverage.json 报告，列出每个语言包的引用次数与来源文件，便于审计
• 把白名单声明移到独立配置（如 locales/active.json），而非散落在代码中，降低维护成本