多语言项目中应通过静态分析提取引用的 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），而非散落在代码中，降低维护成本
