企业官网建设流程全解析

如果今年你还在纠结 React Native 到底能不能在鸿蒙生态里跑起来，那我建议你找个真实项目试一试。我这段时间正好在做一个基于 RN for OpenHarmony 的商城 App，从框架选型、组件适配到多语言设置，踩了不少坑。今天先把“语言设置”这块单独拎出来讲——不是因为别的，而是因为它看着简单，真正做起来涉及的链路比想象中长得多：JS 侧要管文案和切换，原生侧要同步系统语言，后端还要配合下发动态文案，任何一个环节没接好，用户看到的界面就会“半中半英”。

这篇文章我会按照实际项目里的落地顺序来写：先讲为什么语言设置是商城 App 的基础能力，再讲方案选型和资源组织，然后给出一套完整的代码实现，最后把我在 OpenHarmony 上遇到的几个典型坑和排查思路全部列出来。适合正在做 RN 跨端商城、准备把业务迁移到 OpenHarmony、或者单纯想把多语言体系做扎实的开发者参考。如果你是第一次接触 RN for OpenHarmony，我建议先把工程跑起来再回来看本文，代码细节会更对得上。

1. 为什么语言设置是商城 App 的“基础设施”

1.1 商城场景下的多语言需求拆解

普通工具类 App 的多语言，通常就是一堆静态按钮文案和设置页选项，切换完基本就结束了。商城 App 完全不是这个量级。我随便举几个这次项目里遇到的实际场景：

• 商品详情页的标题、描述、卖点、规格参数，每一段都可能是运营从后台录入的富文本。
• 订单状态、售后流程、支付结果这些强状态类页面，文案必须精确对应业务节点，不能出现“翻译到了但语义错了”的情况。
• 营销活动、优惠券规则、满减文案，经常是临时配置、频繁修改，客户端不可能每次都发版跟随。
• 价格、日期、数量这些格式化内容，不单纯是“翻译”，还要处理货币符号、小数点、千分位、复数规则等地区差异。

也就是说，语言设置在商城 App 里不是一个“设置项”，而是一套贯穿 UI、业务、后端的内容分发体系。如果你只是把它当成t('hello')这种翻译调用，后面的坑一个都躲不掉。

1.2 RN for OpenHarmony 带来的特殊挑战

RN 本身有成熟的国际化方案，但 RN for OpenHarmony 是一条相对年轻的适配路线。它的整体思路是：在 OpenHarmony 设备上通过自绘渲染引擎和原生桥接，把 RN 的 JS 层跑起来，同时把原生能力暴露给 JS 调用。

这带来的第一个问题是“语言环境不一致”。应用启动时，JS 侧需要知道当前系统语言是什么、是否应该跟随系统切换。在 Android/iOS 上，RN 有相对成熟的能力可以拿到这些信息；但在 OpenHarmony 上，部分地方不能直接复用，需要自己通过 NativeModule 桥接系统语言 API。

第二个问题是“原生组件的语言不会自动跟随”。比如商城里经常会用到日历选择器、地区选择器、日期时间弹窗，这些如果是原生 HarmonyOS 组件实现的，它们的文案是跟随 OpenHarmony 系统语言的，不一定跟随 App 内切换的语言。你 JS 层切到英文了，弹出来的日期选择器还是中文，体验就很割裂。

第三个问题是“系统字体渲染差异”。OpenHarmony 设备上如果缺少某些字体或者字体回退规则不一致，中英文混排时可能出现字符显示不全、甚至变成方框的情况。这些在语言设置场景里会被放大，因为切换语言后你一定会做一轮全页面文案排查。

2. 方案选型：i18n 框架与资源组织

2.1 为什么选 react-i18next 而不是自研

我见过不少团队在项目初期图省事，自己写一个全局字典对象，再加一个setLanguage方法。这种做法在小工具里没问题，但放到商城 App 里很快就会失控：插值参数、复数规则、多级嵌套、运行时切换联动、后端文案注入，这些要是全自己实现，工作量远超预期。

这次项目我直接选了react-i18next + i18next。理由很简单：

• 支持运行时切换语言，切换后所有绑定了翻译函数的组件会重新渲染，不需要手动刷新页面。
• 内置插值、嵌套、复数、上下文等能力，和商城文案的复杂度匹配。
• 生态成熟，文档齐全，社区里很多现成的格式化和语言包处理方案可以参考。
• 可以方便地对接日志和错误上报，缺 key 时能快速定位。

当然，react-intl也是个好选择，它在格式化方面做得更细，尤其是日期和数字。但我个人的体感是，商城文案里“嵌套翻译 + 插值 + 复数”的组合出现频率最高，react-i18next 的写法更直白，团队上手成本低。最终我甚至没再用单独的日期格式化库，直接用Intl处理，后面会讲到。

2.2 语言包的工程化组织方式

语言包不只是 JSON 文件，它的组织方式直接影响团队协作效率。我这次项目里的目录结构大概是这样：

src/ locales/ zh-CN/ common.json home.json product.json order.json cart.json profile.json en-US/ common.json home.json product.json order.json cart.json profile.json index.ts

按页面模块拆分语言包，而不是把全部文案塞进一个大 JSON。这么做有几层考虑：一是不同模块的文案由不同业务同学维护，拆开以后 review 和 merge 冲突都少；二是按需加载更灵活，以后如果要做语言包动态下发或者懒加载，模块维度是最自然的切分方式；三是避免单文件过大，尤其在低端鸿蒙设备上，一次性加载超大 JSON 会有明显的解析耗时。

index.ts 里统一做导出和类型声明：

import zhCN from './zh-CN/index'; import enUS from './en-US/index'; export const resources = { 'zh-CN': { translation: zhCN }, 'en-US': { translation: enUS }, } as const; export type AppLanguage = keyof typeof resources;

这里用了as const，后续在设置页做语言列表时，可以直接从resources推导出语言代码，避免硬编码字符串。

语言包内部还约定了几条命名规范：所有 key 都按“模块_页面_含义”来组织，比如product_detail_add_cart；带参数的文案统一用插值语法，比如cart_count；复数相关的 key 一律提供单复数两种形式，避免不同语言下数量描述出现语法错误。

2.3 动态下发语言包的考虑

商城文案时效性很强，尤其是活动和公告。我的建议是把语言包分成两层：基础包打进 App，活动包由后端下发。基础包保证核心购买链路在任何情况下都能正常显示；活动包走配置中心下发，前端按 key 合并到 i18next 的 resources 中。

动态下发有一个关键点：语言包要有版本和生效范围。版本可以控制客户端是否拉取最新包，生效范围决定这个文案是只对某个活动生效，还是全局替换。这次项目里我们用了一个简单的映射结构，后端返回的每个文案都是{ zh-CN: '...', en-US: '...' }的键值结构，前端再根据当前语言取对应文案。这样切换语言时，动态文案也会跟着变，不需要重新拉取接口。

3. 实操落地：语言设置从 0 到 1

3.1 工程初始化与依赖安装

先假设你已经有一个能跑的 RN for OpenHarmony 工程。如果还没有，需要先在 OpenHarmony 设备或模拟器上把基础应用跑通，再继续下面的步骤。语言设置本身不依赖特别复杂的环境，但后续验证切换效果必须要有真实设备或模拟器。

依赖方面，我只加了三个核心库：

npm install react-i18next i18next @react-native-async-storage/async-storage

AsyncStorage用来持久化用户的语言选择。如果你项目里已经接了MMKV，用它也行，语言选择这种小 key 使用 AsyncStorage 完全够用，不必为此引入额外原生依赖。

安装完以后，我会先做一件事：确认 RN for OpenHarmony 环境下的I18nManager可用性。RN 自带的I18nManager主要管 RTL，语言信息在很多平台上并不直接暴露，OpenHarmony 上更是如此。所以不要指望I18nManager.getConstants().localeIdentifier一定返回有效值，后面我会专门讲怎么安全地拿系统语言。

3.2 i18next 的初始化配置

语言设置的第一步是正确初始化 i18next。初始化时序很关键：i18n.changeLanguage不能盲目在启动时就调用，必须先确认用户本地存储里有没有之前选择过的语言。

我的初始化文件长这样：

import i18n from 'i18next'; import { initReactI18next } from 'react-i18next'; import AsyncStorage from '@react-native-async-storage/async-storage'; import { resources } from '../locales'; const LANGUAGE_STORAGE_KEY = 'APP_LANGUAGE'; const getInitialLanguage = async (): Promise<string> => { try { const savedLanguage = await AsyncStorage.getItem(LANGUAGE_STORAGE_KEY); if (savedLanguage && resources[savedLanguage]) { return savedLanguage; } // 没有用户选择记录时，跟随系统语言 return getSystemLanguage(); } catch (error) { return 'zh-CN'; } }; export const initI18n = async () => { const initialLanguage = await getInitialLanguage(); i18n.use(initReactI18next).init({ resources, lng: initialLanguage, fallbackLng: 'zh-CN', interpolation: { escapeValue: false, }, react: { useSuspense: false, }, returnNull: false, }); return i18n; };

几个细节说一下。interpolation.escapeValue: false是 RN 场景下的标准配置，因为 RN 的 Text 组件本来就不会把内容当 HTML 渲染，不需要 i18next 再做转义。useSuspense: false避免在异步加载语言包时触发 React Suspense 的 fallback，因为我们的语言包是本地同步加载的，没必要过一层异步逻辑。returnNull: false保证缺 key 时返回 key 本身而不是 null，方便排查。

这里最关键的是getInitialLanguage中的getSystemLanguage()，它需要从原生侧拿到当前系统的语言代码。我在 OpenHarmony 上的实现方式是写一个 NativeModule，壳工程侧通过 system API 获取语言，再同步给 JS 层。下面会单独讲。

3.3 原生侧：OpenHarmony 系统语言获取与监听

RN for OpenHarmony 工程里，HarmonyOS 壳工程是真正的原生项目，RN 桥接层会把 JS 和原生连接起来。我在壳工程里加了一个SystemLanguageModule，对外暴露两个方法：一个是“获取当前系统语言”，一个是“监听系统语言变化”。

ArkTS 侧代码大致是这样：

import { i18n } from '@kit.LocalizationKit'; import { abilityAccessCtrl } from '@kit.AbilityKit'; @NativeModule export class SystemLanguageModule { @JSMethod() getSystemLanguage(): string { // 返回类似 'zh-Hans-CN' 或 'en-US' return i18n.getSystemLanguage(); } @JSMethod() onSystemLanguageChange(callback: (language: string) => void): void { const context = getContext(this); const eventId = 'systemLanguageChange'; i18n.on(eventId, (language: string) => { callback(language); }); } }

这里有两个容易踩的细节。第一，getSystemLanguage()返回的语言标签格式可能是zh-Hans-CN这种带地区甚至带文字方向的写法，而我们的语言包 key 是zh-CN，所以 JS 侧一定要做一层归一化映射，不能直接拿返回值去匹配。第二，监听系统语言变化的回调，要在 App 进入后台再回前台时重新确认一下是否触发，部分设备上系统语言切换后，App 回到前台时事件可能已经发过，但 JS 侧 JS 引擎刚恢复，回调没被及时处理，需要在前台恢复时主动轮询一次当前语言。

JS 侧的封装:

import { NativeModules } from 'react-native'; const { SystemLanguageModule } = NativeModules; const normalizeLanguage = (rawLanguage: string): string => { if (!rawLanguage) { return 'zh-CN'; } if (rawLanguage.includes('zh')) { return 'zh-CN'; } if (rawLanguage.includes('en')) { return 'en-US'; } return 'zh-CN'; }; export const getSystemLanguage = (): string => { try { const raw = SystemLanguageModule?.getSystemLanguage(); return normalizeLanguage(raw); } catch (error) { return 'zh-CN'; } }; export const subscribeSystemLanguageChange = ( callback: (language: string) => void ): (() => void) => { if (!SystemLanguageModule?.onSystemLanguageChange) { return () => {}; } const handler = (rawLanguage: string) => { callback(normalizeLanguage(rawLanguage)); }; SystemLanguageModule.onSystemLanguageChange(handler); return () => { // 反注册逻辑，具体取决于桥接层实现 }; };

注意，所有原生方法的调用都要包一层 try/catch。RN for OpenHarmony 的桥接层还在持续完善，某些自定义 NativeModule 在低版本设备上可能没有被正确注册，一旦调用失败，JS 层至少要能给个兜底语言，不能让 App 白屏。

3.4 设置页 UI 与切换逻辑

语言设置入口通常放在“我的 - 设置”里面，样式上就是一组单选列表。点击某个语言后，需要同时做三件事：更新 i18next 的 language、写入持久化存储、通知原生侧刷新所有原生组件的文案。

设置页核心代码：

import React, { useState } from 'react'; import { View, Text, TouchableOpacity, StyleSheet } from 'react-native'; import { useTranslation } from 'react-i18next'; import AsyncStorage from '@react-native-async-storage/async-storage'; import { resources, AppLanguage } from '../locales'; import { subscribeSystemLanguageChange } from '../native/SystemLanguageModule'; const LANGUAGE_STORAGE_KEY = 'APP_LANGUAGE'; const LanguageSettingScreen = () => { const { t, i18n } = useTranslation(); const [currentLanguage, setCurrentLanguage] = useState<AppLanguage>( (i18n.language as AppLanguage) ?? 'zh-CN' ); const languageOptions: { code: AppLanguage; label: string }[] = [ { code: 'zh-CN', label: '简体中文' }, { code: 'en-US', label: 'English' }, ]; const handleSelectLanguage = async (languageCode: AppLanguage) => { if (languageCode === currentLanguage) { return; } // 1. 更新 i18next await i18n.changeLanguage(languageCode); // 2. 持久化用户选择 await AsyncStorage.setItem(LANGUAGE_STORAGE_KEY, languageCode); // 3. 更新 UI 状态 setCurrentLanguage(languageCode); // 4. 通知原生侧同步语言 // 这里调用的是我们自己封装的一个方法，用于刷新原生组件文案 notifyNativeLanguageChanged(languageCode); }; // 一个可选的增强：当用户没有手动选择语言时，跟随系统语言变化 // 这块是否启用取决于产品策略，商城类 App 通常允许用户“跟随系统”或“固定选择” // 如果做“跟随系统”模式，需要在这里监听系统语言变化回调 return ( <View style={styles.container}> {languageOptions.map((option) => { const isSelected = option.code === currentLanguage; return ( <TouchableOpacity key={option.code} style={styles.optionItem} onPress={() => handleSelectLanguage(option.code)} > <Text style={styles.optionLabel}>{option.label}</Text> <View style={[styles.radioCircle, isSelected && styles.radioCircleSelected]}> {isSelected && <View style={styles.radioDot} />} </View> </TouchableOpacity> ); })} </View> ); }; const styles = StyleSheet.create({ container: { flex: 1, backgroundColor: '#fff', paddingHorizontal: 16, }, optionItem: { flexDirection: 'row', justifyContent: 'space-between', alignItems: 'center', paddingVertical: 16, borderBottomWidth: StyleSheet.hairlineWidth, borderBottomColor: '#e5e5e5', }, optionLabel: { fontSize: 16, color: '#333', }, radioCircle: { width: 20, height: 20, borderRadius: 10, borderWidth: 2, borderColor: '#ccc', alignItems: 'center', justifyContent: 'center', }, radioCircleSelected: { borderColor: '#ff5000', }, radioDot: { width: 10, height: 10, borderRadius: 5, backgroundColor: '#ff5000', }, });

这里有一个产品层面的设计取舍需要提前想清楚：语言设置是“用户手动选择语言”还是“跟随系统语言”。商城类 App 通常两者都想要，但实现方式不同。

如果做“跟随系统模式”，逻辑是：用户没有手动选过语言时，系统语言一旦变化，App 文案也跟着变。这个需要在 App 启动时注册subscribeSystemLanguageChange，并在回调里调用i18n.changeLanguage(newLanguage)。如果用户手动选过语言，则不再跟随系统，以用户选择为准。

如果做“固定选择模式”，逻辑会简单很多：完全以用户选择为准，App 启动直接读AsyncStorage，没有记录才用系统语言做初始值。这次项目我两种模式都实现了，通过一个AppLanguageMode状态来区分。默认给的是“跟随系统 + 可手动覆盖”，对商城场景比较友好，能兼顾大多数用户的使用习惯。

3.5 重启还原与启动流程整合

语言设置最怕“设置完以后一重启就回到原样”。这种问题通常不是因为逻辑写错了，而是 i18next 初始化的时机早于异步存储读取完成。

我之前踩过一次：在模块顶部直接执行i18n.init()，默认语言写死成zh-CN，启动后再去读AsyncStorage，读到了en-US再changeLanguage。看起来好像也没问题，但页面上会有短暂的中文闪现，用户感知非常明显，而且在启动页到首页这段过渡会触发一次多余的重渲染，严重时甚至可能导致 i18next 内部的changeLanguage与页面首帧渲染竞争，出现部分组件没刷新过来的情况。

所以正确做法是把初始化流程串起来：

// 入口文件 const bootstrap = async () => { await initI18n(); // 注册原生语言变化监听 registerSystemLanguageListener(); // 再启动 React 应用 AppRegistry.registerComponent(appName, () => App); };

用await initI18n()保证语言资源在应用渲染前已经就绪，这样首帧就是正确语言，不会闪一下。对于商城来说，启动首帧如果先闪中文再跳英文，转化率层面虽然影响不大，但给用户的“这 App 不专业”的印象是实打实的。

4. 商城场景进阶：格式化与动态文案

4.1 价格、日期、数量的地域化

语言设置做到这一步，基础切换已经完成，但在商城 App 里还远远不够。真正让用户觉得“这个 App 是为我做的”，往往是价格、日期、数量这些细节。

价格格式化是最典型的。同一个商品，在国内显示¥129.00，在英文环境里可能需要显示$129.00或者USD 129.00，这取决于你的商城目标市场。RN 的 JS 引擎在鸿蒙设备上支持Intl吗？实测下来，Intl.NumberFormat的大部分功能是可用的，但不能 100% 依赖。我的做法是封装一个自己的格式化工具，优先用Intl，失败时用正则手动拼。

const formatPrice = (amount: number, currency: string, locale: string) => { try { return new Intl.NumberFormat(locale, { style: 'currency', currency, minimumFractionDigits: 2, maximumFractionDigits: 2, }).format(amount); } catch (error) { // 兜底方案：手动拼符号 return `${currency} ${amount.toFixed(2)}`; } };

注意，引擎是否支持Intl和是否支持某个locale是两回事。在 OpenHarmony 的 JS 引擎上，Intl.NumberFormat('en-US', ...)一般没问题，但如果你传了一个比较偏门地区的 locale，引擎不一定能正确识别，就会出现返回结果不在预期的情况。所以我对 locale 参数也做了白名单处理，只允许传zh-CN或en-US，其他一律走 fallback。

数量复数规则是一个容易被忽略的点。中文里“1 件商品”“5 件商品”的“件”不需要变化，英文里却区分1 item和5 items。i18next 内置的复数机制可以通过 key 后缀解决：

// en-US { "cart_item_count_one": "{{count}} item", "cart_item_count_other": "{{count}} items" }

t('cart_item_count', { count: 5 });

i18next 会自动根据当前语言的复数规则选择合适的 key。这里要给团队提个醒：中文翻译文件里不适合照搬英文的_one/_other结构，中文通常只写一种形式即可。如果不注意，很容易在中文语言包里也塞两个 key，结果是数量变化时文案没任何区别，纯属冗余。

日期和时间的处理类似。订单列表的时间戳、活动倒计时、售后倒计时，这些都要根据语言环境切换格式。我建议不要在语言包 JSON 里手工拼日期格式，尽量用统一工具函数按当前语言输出格式，比如zh-CN输出2025-06-01 14:30，en-US输出Jun 1, 2025, 02:30 PM。

4.2 后端动态文案的多语言策略

商城运营位、公告、商品卖点这类内容，多数是后端配置的。客户端如果只负责翻译固定 UI 文案，那语言设置功能是不完整的。

动态文案在接口层常见两种做法：

第一种是后端直接返回多语言 Map。比如商品详情接口返回title: { "zh-CN": "...", "en-US": "..." }，前端根据当前语言取对应字段。这种做法的好处是客户端逻辑简单，切换语言后重新请求一次接口即可拿到新的文案；坏处是接口传输体积变大，且要求所有后端接口都遵循同一套多语言字段规范。

第二种是前端维护一张“文案 ID 到多语言内容”的映射表，接口只返回文案 ID，前端自己拿当前语言去映射。这种做法适合活动页这种内容高度复用的场景，但成本是要维护一套额外的映射管理后台，而且文案实时更新的时效性取决于映射表下发是否及时。

这次项目里，我们用的是“混合模式”：核心交易链路（商品名、规格、签约条款）走后端 Map 方式，保证准确性和时效性；营销物料（banner、金刚区运营文案）走前端映射表方式，方便运营快速配置和预览。

无论用哪种方式，都要注意一点：当用户在设置页切换语言后，当前页面的动态文案必须及时刷新。如果是接口 Map 方式，需要在语言切换后重新拉取依赖语言的接口；如果是前端映射表方式，需要把映射表也放进 i18next 的 language 资源里一起管理，切换时组件自动重渲染。

4.3 原生弹窗和组件的语言同步

商城 App 里大量使用了原生组件，尤其是日期选择器、城市选择器、Toast 和 AlertDialog。这些组件在 iOS/Android 上通常直接读取系统语言；但在 OpenHarmony 上，它们读的是 OpenHarmony 系统语言，不一定和 App 内选择的语言一致。

我在这个项目里遇到一个很具体的例子：用户在设置页把 App 语言切到英文，然后进订单筛选，选了一个“发货时间范围”，弹出的原生日期选择器仍然是中文。原因就是这个日期选择器由壳工程的 ArkUI 组件实现，它的文案资源走的是 OpenHarmony 的 i18n 资源，框架本身不知道 App 内语言已经切换了。

解决办法是在语言切换时，通过一个全局事件把手动选择的语言同步给壳工程，壳工程再根据语言重新配置相关组件的 locale 资源。具体实现上，可以用 RN 和原生之间的事件通信，也可以做成 NativeModule 的setAppLanguage方法：

@NativeModule export class AppLanguageModule { @JSMethod() setAppLanguage(language: string): void { // 更新原生侧的语言偏好，用于原生组件的文案 AppStorage.setOrCreate('appLanguage', language); } }

然后在handleSelectLanguage里调用：

NativeModules.AppLanguageModule?.setAppLanguage(languageCode);

这块没有统一的万能方案，关键是你需要提前盘一下项目里到底用了哪些原生组件，哪些自带语言资源。盘完以后列一份清单，写进语言切换的联动逻辑里，不要漏。

5. 踩坑记录与排查技巧

5.1 常见问题速查表

下面这个表是我这次项目里的实际问题记录，不是从文档里抄来的。直接照着排查能省不少时间。

5.2 三个我印象最深的坑

第一个坑是字体缺失导致的“口字”问题。OpenHarmony 设备上，如果系统没有安装全量的中文字体，切换语言到中文后，部分生僻字或者特殊符号会直接显示成方框。商城商品名里偶尔会出现品牌方的生僻字，很影响观感。排查下来发现是系统字体回退机制在鸿蒙设备上表现不一致。我的处理办法是：在 App 内置一套常用的 fallback 字体资源，对文本样式统一设置fontFamily，优先使用鸿蒙标准字体，再指定一个包含完整字符集的备选字体。这个方案虽然简单，但对语言体验的提升非常明显。

第二个坑是归一路由逻辑写得太“乐观”。我一开始直接用系统返回的rawLanguage去i18n.changeLanguage了，结果系统返回的是zh-Hans-CN，而我的语言包 key 是zh-CN，导致匹配不上，所有文案全部走 fallback，页面变成了“半中半英”的混合状态。后来我加了normalizeLanguage映射，把所有包含zh的都归一化到zh-CN，包含en的都归一化到en-US，问题立刻解决。做语言设置的同学一定要意识到：语言标签格式在 iOS、Android、OpenHarmony 上并不完全统一，甚至 OpenHarmony 自己的不同版本之间都可能存在差异，归一化映射是必须的。

第三个坑是原生语言事件在 App 从后台回前台时的丢失。在部分鸿蒙设备上，用户切换到系统设置改了语言，再切回 App，系统语言变化事件在 App 还处于后台时就已经触发了，而 JS 引擎那时候可能被系统挂起，事件没被消费。等用户回到前台，App 显示的还是旧语言。这个问题的修复方式是在 App 的AppState监听里增加一次“回前台主动读取系统语言并比对”的逻辑，事件监听和主动轮询双保险，才能覆盖所有设备的调度策略差异。

6. 一些额外的经验总结

语言设置这个模块，在整个商城项目里看起来占比不大，但它牵涉的链路确实很长：从语言包组织、初始化时序、原生桥接、后台动态文案到格式化规则，每一步都有讲究。做完以后我有几个比较深的体会。

如果你还在开发阶段，一定要尽早把语言设置接入，不要等到业务页面全铺开了再补。越晚接入，硬编码文案越多，全局替换成本越高。我自己这次因为前期已经用了统一的t()封装，替换成本还相对可控；但即便这样，还是有漏网之鱼，测试阶段专门花了一轮去全量排查硬编码字符串。

语言设置和调试要结合起来做。我建议在开发环境把 i18next 的 debug 打开，这样每次渲染时控制台会打印出所有翻译过的 key，一旦出现缺失 key，立刻就能在日志里看到。上线前再做一轮“破坏性测试”——把语言包里的某个 key 临时删除，看看页面会不会白屏、会不会崩溃、会不会显示乱码，正常情况下应该只是当前文案变成 key 本身，不影响其他功能。

最后再分享一个小技巧。我们给语言包加了一个版本号，由接口下发，比如当前语言包版本是20250601，客户端拉下来后发现和自己本地的版本不一致，就重新拉取语言包。这个机制后来帮我们避免了好几次“运营改了文案，用户却看不到”的投诉，强烈推荐团队都加上。

如果后续还想继续深入，可以考虑做语言包的按需加载，以及结合chunk方式把不常用模块的文案从主包拆出去，尤其是当商城 SKU 规模变大、运营文案数量变多之后，这一项优化能实打实降低首包体积。语言设置这个功能，做“能用”容易，做“好用”确实要花不少心思，希望这篇记录能给你省下一些摸索时间。