简介：这份资源面向在 Visual Studio 2015 下使用 MFC 开发桌面程序的工程师，解决界面文本难以随语言切换、国际化改造成本高的问题。内容围绕多语言资源文件的组织、POEdit 翻译流程与 MO 语言包加载展开，演示如何通过资源句柄切换与字符串替换实现中英文界面动态切换，并兼顾界面布局对不同语言文本长度的适配。资源包共 28 个文件，约 1.18MB，包含 h 头文件与 cpp 源文件构成的核心代码、rc 与 rc2 资源脚本、po 与 mo 双语翻译文件，以及 sln 解决方案、vcxproj 工程配置和可执行程序与动态库，拿到即可编译运行并对照改造自己的项目。目前已有 1388 人学习下载，适合具备一定 MFC 基础、希望为产品补充国际化能力的中级开发者参考。

1. 老界面要加英文版：MFC 多语言切换真正难的地方

接手一个跑了七八年的 MFC 项目，客户临时要求加英文和繁体两套界面。第一反应是把字符串全挪进 String Table，再给每种语言编一个资源 DLL，运行时换句柄；真动手才发现，硬编码在SetWindowText、AfxMessageBox、CString::Format里的界面文案有两千多处，光靠资源段根本盖不住。折腾两轮之后我换成 gettext 那套：源码里写_T("确定")，词条表用 po 文件维护，poedit 做翻译，编译成 mo 语言包，运行时按语言目录加载。MFC 多语言切换这件事，难点从来不是翻译本身，而是把散落在各处的界面文案收拢成一条可维护、可热切换的链路。下面这份实现就是按这个思路搭起来的。

2. 工程骨架与选型：po/mo 语言包为什么比资源 DLL 更适合老项目

做 MFC 多语言切换，往下走的第一步不是写代码，是决定词条存在哪儿。这一步选错，后面每加一种语言都得推倒重来。我在这类老项目上先后用过三种方案，把差异摊开讲清楚，省得你改到一半才发现方向不对。

2.1 三种方案的取舍：资源 DLL、内嵌 XML、gettext po/mo

资源 DLL 是 MFC 的原生路子：字符串和对话框模板放资源里，每种语言编一个 resource-only DLL，启动或切换时AfxSetResourceHandle换句柄。好处是菜单、对话框、String Table 一起换，和 MFC 贴合；坏处是老项目里pWnd->SetWindowText(_T("确定"))这种硬编码完全管不到，而且每加一种语言就得让翻译人员拿到 .rc 文件、装一套 VS 环境，重新编一次 DLL，交付周期长得离谱。

内嵌 XML/JSON 是很多人退而求其次的选择：一个lang_zh.xml管所有词条，程序启动解析成 map，key 自己起名。解析好写、热更新好做，但源码会变成_T("IDS_BTN_OK")满天飞，读代码时根本看不出这句显示什么，新人接手得对着两个文件来回翻。键名一旦起乱，后期维护成本比想象中高。

gettext 的 po/mo 方案刚好卡在中间：msgid 就是原文本身，源码里_T("确定")一眼能读懂；翻译文件是纯文本 po，poedit 这类工具支持翻译记忆、拼写检查、未翻译条目高亮；新增一种语言只是往 lang 目录塞一份 mo，程序一行不改。

表格最后一列是 po/mo 的真实短板：菜单和对话框上的文字是编译进资源里的，gettext 管不到。所以工程里必须额外写一层"资源文字重载"，遍历菜单和子控件，把拿到的原文丢进查表函数再写回去。这部分代码是绕不开的，但写一次就够，后面所有语言通用。

选 po/mo 还有一个不那么显性、但在实际交付里很值钱的理由：词条文件和代码是解耦的。发版之后客户说某句英文翻译得别扭，你只需要让对方发一份改过的 mo 过来替换，不用重新打包整个安装程序。这种"翻译可独立迭代"的能力，在资源 DLL 方案里几乎做不到。

2.2 目录与文件编排：一个 lang 目录装下所有语言包

目录结构我沿用了 gettext 的惯例，好处是以后要接标准工具链时零成本，也方便运维一眼看懂哪个目录对应哪门语言。

DemoApp/ ├── src/ │ ├── Lang.h # 单例声明、_() 宏 │ ├── Lang.cpp # mo 解析、查表、编码转换 │ ├── LangUi.cpp # 菜单/控件文字重载 │ └── MainFrm.cpp ├── lang/ │ ├── messages.pot # 模板，从源码扫描出来的词条 │ ├── zh_CN/ │ │ ├── app.po # 中文词条（源语言，一般留空翻译） │ │ └── LC_MESSAGES/app.mo │ ├── en_US/ │ │ ├── app.po │ │ └── LC_MESSAGES/app.mo │ └── zh_TW/ │ ├── app.po │ └── LC_MESSAGES/app.mo └── res/

LC_MESSAGES这层看着多余，但它是 gettext 的事实标准，poedit 默认就按这个结构导出，很多现成的校验脚本也认这个路径。自己另起一套lang/en_US/app.mo也能跑，只是以后想借用生态工具时得再写一层适配。我一般宁可多一层目录，也不给自己埋这种小坑。

messages.pot是词条模板，只存 msgid 不存译文，由脚本从源码里扫出来。它的作用是给翻译人员一个"当前版本有哪些新词条"的基准：把 pot 和上一版 po 做合并，新词条会以空翻译的形式出现，poedit 打开就能看到一堆待翻译项。没有这一步，新增的界面文案就只能靠人工比对，漏翻是迟早的事。

2.3 加载与切换时机：InitInstance、注册表与热刷新

语言加载的时机比很多人想的要早。必须放在InitInstance里、主窗口Create之前，否则主框架的标题栏、初始菜单已经按默认语言画完了，再切就是二次刷新，闪一下很难看。

BOOL CDemoApp::InitInstance() { CWinApp::InitInstance(); // 语言必须在任何窗口创建之前就绪 CLang& lang = CLang::GetInstance(); lang.SetLanguage(ReadLanguageFromProfile()); // 读注册表/ini，没有就跟随系统 lang.LoadMo(lang.GetMoPath()); // 失败不致命，回退到原文 CMainFrame* pFrame = new CMainFrame(); m_pMainWnd = pFrame; pFrame->LoadFrame(IDR_MAINFRAME); return TRUE; }

SetLanguage只负责记录当前语言代码并拼出 mo 路径，LoadMo负责把词条读进哈希表。两个动作分开的好处是：切换语言时可以只调LoadMo重新装载，不用重建整个 App 对象。

用户选择语言我存在注册表HKCU\Software\<产品名>\Language下，键值就是zh_CN、en_US这种标准代码。首次启动没有这个键时，走GetUserDefaultUILanguage()判断系统语言，命中不了就回落到中文——源语言是中文，回落过去至少能看懂，不会出现满屏英文的尴尬。

切换动作本身分两种。省事的做法是提示用户"重启后生效"，改完注册表就退出，下次启动自然加载新语言。这种做法代码量最小，但体验差一截。我倾向做热刷新：重新LoadMo，然后遍历主菜单、所有已打开的对话框子控件，把文字重写一遍，再Invalidate一次。热刷新的坑集中在"哪些控件不该刷"上，后面排查章节会细说。

3. 核心代码拆解：从 _T("确定") 到屏幕上那三个字的完整链路

整条链路其实只有四段：宏把原文送进单例、单例在哈希表里查、查不到回退原文、查到了回写控件。一段一段看。

3.1 宏与编码桥接：CString / TCHAR / UTF-8 之间的转换

先约定一件事：工程切到 Unicode 字符集。这不是洁癖，是为了让CString、LPCTSTR、std::wstring三者类型一致，省掉大量#ifdef _UNICODE的噪音。没切的项目建议在动手前先切，越往后成本越高。

// Lang.h #pragma once #include <string> #include <unordered_map> // 界面文案统一走这个宏，别直接调单例，将来换实现只改一行 #define _(s) CLang::GetInstance().Tr(s) class CLang { public: static CLang& GetInstance(); void SetLanguage(const CString& code); // "zh_CN" / "en_US" CString GetLanguage() const { return m_code; } CString GetMoPath() const; // lang/<code>/LC_MESSAGES/app.mo bool LoadMo(const CString& path); CString Tr(LPCTSTR src); // 查不到就返回原文 private: CLang() {} std::unordered_map<std::wstring, std::wstring> m_map; CString m_code; };

Tr收LPCTSTR，在 Unicode 工程下就是const wchar_t*，和CString隐式互转没有额外开销。返回CString而不是const wchar_t*，是为了能直接接SetWindowText、Format这些接口，写起来顺畅。

mo 文件里存的是 UTF-8，装进 map 之前必须转成 UTF-16，否则中文会变成一堆问号。这个转换函数全程只用一个地方，我把它抽成静态工具：

// 严格按 UTF-8 解码，不做 ACP 猜测 static std::wstring Utf8ToWide(const std::string& s) { if (s.empty()) return std::wstring(); int n = ::MultiByteToWideChar(CP_UTF8, MB_ERR_INVALID_CHARS, s.data(), (int)s.size(), nullptr, 0); if (n <= 0) return std::wstring(); // 非法字节序列，宁可返回空也不乱码 std::wstring w(n, L'\0'); ::MultiByteToWideChar(CP_UTF8, MB_ERR_INVALID_CHARS, s.data(), (int)s.size(), &w[0], n); return w; }

MB_ERR_INVALID_CHARS这个标志别省。不带它时，非法 UTF-8 会被静默替换成替换字符，界面上看起来是"某个字变成了方块"，排查时你根本不知道是词条文件坏了还是代码有问题。带上它，坏文件在加载阶段就暴露，LoadMo返回 false，程序退回原文，界面至少是完整的。

3.2 词条查表与单例：手写 mo 解析，不引 libintl

mo 是二进制格式，很多人第一反应是引 libintl 或 gettext 的库。但 MFC 工程引第三方 C 库会带来一堆运行时依赖和编译选项问题，而我们需要的功能其实只有"读表"这一件事。mo 的格式简单到可以手写：文件头 7 个 uint32，后面两张表分别记录原文和译文的长度与偏移。

bool CLang::LoadMo(const CString& path) { std::ifstream f(path, std::ios::binary); if (!f) return false; f.seekg(0, std::ios::end); size_t size = (size_t)f.tellg(); if (size < 28) return false; // 连文件头都不够 f.seekg(0, std::ios::beg); std::vector<char> buf(size); f.read(buf.data(), (std::streamsize)size); const unsigned char* p = (const unsigned char*)buf.data(); auto rd32 = [&](size_t off) -> uint32_t { // mo 全部小端 return (uint32_t)p[off] | ((uint32_t)p[off + 1] << 8) | ((uint32_t)p[off + 2] << 16) | ((uint32_t)p[off + 3] << 24); }; if (rd32(0) != 0x950412de) return false; // 魔数不对，文件不是 mo uint32_t n = rd32(8); uint32_t origOff = rd32(12); uint32_t transOff = rd32(16); if (origOff + n * 8 > size || transOff + n * 8 > size) return false; std::unordered_map<std::wstring, std::wstring> fresh; fresh.reserve(n); for (uint32_t i = 0; i < n; ++i) { uint32_t oLen = rd32(origOff + i * 8); uint32_t oPos = rd32(origOff + i * 8 + 4); uint32_t tLen = rd32(transOff + i * 8); uint32_t tPos = rd32(transOff + i * 8 + 4); if (oPos + oLen > size || tPos + tLen > size) continue; // 单条坏了跳过，不整份作废 std::string key((const char*)p + oPos, oLen); std::string val((const char*)p + tPos, tLen); if (val.empty()) continue; // 空翻译视为未翻译，保留原文 fresh[Utf8ToWide(key)] = Utf8ToWide(val); } m_map.swap(fresh); // 整体替换，切换语言时不留旧词条 return !m_map.empty(); }

几个参数和分支值得单独说。rd32用四个字节手工拼，是因为 mo 规范写死小端，而大端机器虽然罕见，用memcpy到 uint32 再判断字节序反而更绕。oPos + oLen > size这类越界检查必须做，po 编译工具输出版本不一致时，表里的偏移有可能对不上，不检查就是越界读，Release 下崩得莫名其妙。最后m_map.swap(fresh)而不是m_map = fresh，是为了在切换语言失败时保住上一份词条——fresh是局部变量，解析途中任何异常都不会污染现有语言。

continue跳过空翻译这一条，对应的是 poedit 里那种"词条存在但译文还没填"的状态。这种条目不进 map，Tr查不到会回退原文，界面上显示中文原文而不是空白，比显示空字符串友好得多。

查表函数本身很短，但回退逻辑是整套方案的安全网：

CString CLang::Tr(LPCTSTR src) { if (src == nullptr) return CString(); if (m_map.empty()) return CString(src); // 语言包没加载成功，全量回退 auto it = m_map.find(std::wstring(src)); if (it == m_map.end()) return CString(src); // 单条没命中，只回退这一条 return CString(it->second.c_str()); }

两层回退是有意设计的：整个语言包加载失败时，程序仍然是一套完整的中文界面，而不是满屏空白；单条词条缺失时，只影响那一句。这套设计让"翻译没跟上开发进度"从致命问题降级成体验瑕疵，实际项目里这一点非常重要，因为界面文案的变更速度永远快过翻译交付速度。

3.3 界面刷新：菜单、对话框、控件三条路径各刷各的

资源里的文字不受 gettext 管理，必须自己遍历重写。菜单和对话框控件是两条不同的路径，代码不能混着写。

菜单要处理分支、加速键文本和&快捷符。GetMenuString拿到的可能是"打开(&O)\tCtrl+O"，直接整串丢进查表函数必然查不到，得先把\t后面的部分拆出来单独保留。

void CLangUi::RefreshMenu(CMenu* pMenu, CLang& lang) { if (pMenu == nullptr) return; UINT count = pMenu->GetMenuItemCount(); for (UINT i = 0; i < count; ++i) { CString text; pMenu->GetMenuString(i, text, MF_BYPOSITION); if (!text.IsEmpty()) { CString caption = text, accel; int tab = caption.Find(_T('\t')); if (tab >= 0) { accel = caption.Mid(tab); caption = caption.Left(tab); } CString tr = lang.Tr(caption); if (tr != caption) // 没变化就别改，减少一次重绘 pMenu->ModifyMenu(i, MF_BYPOSITION | MF_STRING, pMenu->GetMenuItemID(i), tr + accel); } CMenu* pSub = pMenu->GetSubMenu(i); // 递归子菜单 if (pSub) RefreshMenu(pSub, lang); } }

ModifyMenu的第三个参数必须是原来的菜单项 ID，取错了会把命令映射整个打乱，点击菜单没反应就是这么来的。MF_BYPOSITION表示按位置而不是按 ID 定位，遍历时必须带上。tr != caption这个判断看着可有可无，但菜单重绘是有成本的，几十个菜单项全量ModifyMenu会让切换动作肉眼可见地卡一下。

对话框控件走EnumChildWindows，但有个前提：只刷静态文本、按钮、分组框，绝不能碰编辑框和列表控件。

static BOOL CALLBACK RefreshChildProc(HWND hWnd, LPARAM lParam) { CLang* lang = (CLang*)lParam; wchar_t cls[64] = { 0 }; ::GetClassNameW(hWnd, cls, 64); // 白名单：只管展示型控件，用户输入的内容不能被翻译 if (wcscmp(cls, L"Static") != 0 && wcscmp(cls, L"Button") != 0) return TRUE; int len = ::GetWindowTextLengthW(hWnd); if (len <= 0) return TRUE; std::wstring text(len, L'\0'); ::GetWindowTextW(hWnd, &text[0], len + 1); text.resize(len); CString tr = lang->Tr(text.c_str()); if (tr != CString(text.c_str())) ::SetWindowTextW(hWnd, tr); return TRUE; }

类名白名单这一步是血泪经验。早年图省事直接对所有子窗口SetWindowText，结果切换语言时把用户在编辑框里填了一半的内容、列表控件里的数据行全刷成了词条原文，退都退不回来。GetWindowTextLength先取长度再分配缓冲，比固定开 512 字节的GetBufferSetLength稳妥，长文案不会截断。

状态栏文字不在子控件枚举范围内，得单独处理：CStatusBar::SetPaneText按索引逐个设置。面板索引和字符串资源 ID 的映射关系最好写成一张静态表，切换语言时按表遍历，别在代码里散落一堆SetPaneText(1, ...)。

3.4 用 poedit 维护词条：提取、翻译、编译三步

词条不是手写出来的，是扫出来的。写个小脚本按正则从源码里捞_T("...")和_("...")，生成 pot 模板，翻译人员拿 pot 去 poedit 里填译文。

import re, pathlib # 只认 _( "..." ) 和 _T( "..." ) 两种写法，避免误伤普通字符串 PATTERN = re.compile(r'_T\(\s*"((?:[^"\\]|\\.)*)"\s*\)|_\(\s*"((?:[^"\\]|\\.)*)"\s*\)') entries = set() for p in pathlib.Path("src").rglob("*"): if p.suffix.lower() not in (".cpp", ".h"): continue for m in PATTERN.finditer(p.read_text(encoding="utf-8", errors="ignore")): s = m.group(1) or m.group(2) if s: entries.add(s) with open("lang/messages.pot", "w", encoding="utf-8") as f: f.write('msgid ""\nmsgstr ""\n"Content-Type: text/plain; charset=UTF-8\\n"\n\n') for s in sorted(entries): f.write('msgid "%s"\nmsgstr ""\n\n' % s) print("extracted", len(entries))

这个脚本不追求通用性，够用就行。正则排除转义符号那一段不能省，否则遇到_T("路径:\"C:\\Temp\"")这种带引号的文案会把词条截断。生成的 pot 里必须写明charset=UTF-8，poedit 靠这一行判断文件编码，写错了整个文件的中文在编辑器里就是乱码。

翻译完成后在 poedit 里"保存"会自动生成同名 mo，也可以单独用msgfmt编。mo 要放到lang/<语言代码>/LC_MESSAGES/app.mo，路径拼错是新手最常见的失败原因——程序不报错，只是所有词条都回退到原文，看起来像"翻译没生效"。

4. 跑起来：从空工程到中英切换跑通的完整步骤

前面讲的是设计，这一章全是可执行动作。按顺序走一遍，中间任何一步失败都能定位。

4.1 环境与依赖：字符集、MFC 链接方式、语言包

开发环境用 VS2019 或 VS2022，安装时勾上"使用 C++ 的桌面开发"里的 MFC 组件。工程属性里两个设置必须确认：字符集设为 Unicode，MFC 使用方式选"在共享 DLL 中使用 MFC"或"静态库"都行，但整个解决方案里所有工程要一致，混用会在链接期报一堆重定义。

这套实现不依赖 libintl，也不需要编 gettext 库，字符编码转换全部走MultiByteToWideChar和WideCharToMultiByte，属于系统 API。这一点对部署很关键：安装包里只需要多带一个 lang 目录，不新增任何运行时 DLL，客户现场不会因为缺库起不来。

.mo文件本身是二进制，不需要额外注册或安装。整个语言包就是几个几十 KB 的文件，随程序目录走，绿色部署直接可用。

4.2 把 lang 目录带进输出目录

开发期最烦的是每次编译完手动拷语言包。用生成后事件解决：

rem 编译完成后把语言包同步到输出目录，/D 用于跳过只读文件 if not exist "$(OutDir)lang" mkdir "$(OutDir)lang" xcopy /E /I /Y /D "$(ProjectDir)lang" "$(OutDir)lang"

$(OutDir)是输出目录，$(TargetDir)是可执行文件所在目录，两者在多配置（Debug/Release、Win32/x64）下路径不同，用$(OutDir)更稳。/D表示只覆盖源文件更新的部分，语言包大的时候能省不少编译等待。

语言代码的默认值也要有兜底逻辑，别让首次启动因为读不到注册表就崩：

CString CDemoApp::ReadLanguageFromProfile() { CString code; CRegKey key; if (key.Open(HKEY_CURRENT_USER, _T("Software\\DemoApp"), KEY_READ) == ERROR_SUCCESS) { TCHAR buf[32] = { 0 }; ULONG n = 32; if (key.QueryStringValue(_T("Language"), buf, &n) == ERROR_SUCCESS && _tcslen(buf) > 0) code = buf; } if (code.IsEmpty()) { // 没有配置就跟随系统；非中文系统一律回落英文，中文系统用简体 LANGID lid = ::GetUserDefaultUILanguage(); code = (PRIMARYLANGID(lid) == LANG_CHINESE) ? _T("zh_CN") : _T("en_US"); } return code; }

PRIMARYLANGID只取主语言 ID，繁体系统也会命中LANG_CHINESE，所以真实项目里还要再看SUBLANGID区分zh_TW和zh_CN。这里写成示例是为了说明结构，别照抄。

4.3 验证清单：切换完到底要检查哪几处

语言包加载成功不等于界面就对了。每次改完翻译或新增控件，我按下面这张表过一遍，能挡住九成问题。

"模态对话框只有首次打开是新的"这一条值得单独解释：对话框模板里的文字在DoModal时从资源加载，如果你在OnInitDialog里没做重载，第二次打开还是老文字。解决办法是在每个对话框的OnInitDialog里统一调一次CLangUi::RefreshDialog(this)，或者在基类里重写DoModal集中处理，后者更省事，也不容易漏。

5. 避坑与排查：多语言切换上线后最容易翻车的五个地方

这些坑基本都是真实项目里踩出来的，症状看似无关，根因集中在编码和刷新范围两件事上。

5.1 编码与乱码：看着是翻译问题，其实是字节问题

现象一：英文界面正常，中文界面出现成片的问号和方块。原因：工程还是多字节字符集，CString底层是char，MultiByteToWideChar解出来的 UTF-16 又被按 ACP 转回去，非 ASCII 字符在这一来一回中丢了。也可能是 po 文件存成了 GB2312，poedit 虽然能打开，但编译出的 mo 里不是 UTF-8。 解决：工程属性里把字符集改成"使用 Unicode 字符集"，po 文件统一 UTF-8 无 BOM 保存，mo 编译前用十六进制看一眼文件头是不是DE 12 04 95。BOM 特别坑，带 BOM 的 po 会让第一条 msgid 前面多出三个字节，那条词条永远查不到。

现象二：某些词条翻译明明填了，界面上还是原文。原因：源码里的字符串和 po 里的 msgid 差了一个不可见字符——最常见的是全角空格、行尾空格，或者CString拼接后传入的是一整串"确定 "。查表是严格字符串比较，差一个字节都命中不了。 解决：提取脚本里对词条做一次strip()并统一换行符，同时在Tr的调试版本里加日志，把没命中的原文打到 Output 窗口。上线前跑一遍全量界面，把日志里的漏网词条补进 po。

现象三：Format拼出来的句子词序错乱。原因：_T("共 %d 个文件")这类句子把数字嵌在中间，英文语序和中文不同，直译会变成 "Total %d files" 还算好，遇到语序差异大的语言就崩了。 解决：能拆就拆成两段，前缀一段、后缀一段分别翻译；实在拆不开就用%1、%2带位置参数的格式，让翻译方自己调整顺序。别用%s直接拼整句，那是给自己找麻烦。

5.2 刷新范围与资源：刷多了比刷少了更麻烦

现象四：切换语言后，编辑框里用户填的内容被清空或被翻译。原因：EnumChildWindows的回调里没做类名过滤，对所有子窗口调了SetWindowText。编辑框里是用户输入，不是界面文案，被当成词条查表自然查不到，回退成原文时就把用户内容覆盖掉了。 解决：回调开头加类名白名单，只处理Static、Button、GroupBox。对确实需要动态改文字的编辑框，用控件 ID 单独处理，别指望通用遍历。

现象五：Debug 下一切正常，Release 包切换语言直接崩。原因：LoadMo里读文件用了std::ifstream，Release 下tellg()在某些网络路径返回 -1，强转成size_t就是天文数字，vector分配直接抛异常；或者路径里带中文，CString转std::ifstream的窄字符路径时按 ACP 编码，非中文系统下打不开文件。 解决：tellg()结果先判断>= 0再用；文件打开统一走_wfopen或std::ifstream的wchar_t*重载，绕开窄字符路径。这类问题在开发机上永远复现不了，只能靠代码审查和边界判断提前防住。

6. 二次开发：从两种语言扩到 N 种，并做成可热更新的语言包

这套骨架真正值钱的地方在于扩展成本极低。加一门语言只需要三步：在lang下建ja_JP/LC_MESSAGES目录，拿messages.pot翻译成app.po，用 poedit 编出app.mo丢进去。程序代码一行不用动，因为语言列表是扫目录得来的，不是写死的枚举。

如果要做成"语言包独立分发、用户自己下载安装"的形态，改动集中在一个函数上：把LoadMo的路径参数从固定拼装改成从配置文件读。配置文件里存语言代码、显示名、mo 相对路径三列，界面上的语言下拉框直接遍历这份配置生成。这样新增语言连重新发版都不用，运维传个 zip 上去就行。

热更新的验证方式我一般这么走：先在一台没装过任何语言的干净机器上跑一遍完整流程，再故意把 mo 文件改坏一个字节，确认程序退回到原文而不是崩溃，最后把语言目录整体改名，确认程序在找不到语言包时仍能正常启动。这三步走完，才算这套多语言实现真的能交付。

踩过最疼的一次是客户现场升级，安装程序只覆盖了 exe 没覆盖 lang 目录，新版本加了十几个控件，词条全在但界面一半英文一半中文。从那以后我每次发版前都强制走一遍"删掉 lang 目录再启动"的降级测试，确认最坏情况下界面仍然是完整可用的。希望帮到你。

本文还有配套的精品资源，点击获取