前陣子把團隊維護了多年的 Flutter 應(yīng)用遷到 HarmonyOS 平臺功能代碼倒沒折騰太久真正卡住我的反而是本地化這套東西。項目長期用 gettext 體系管理翻譯PO 文件累積了上萬條文案后端、運營和外包翻譯全都圍著這套資產(chǎn)轉(zhuǎn)。我的目標很明確讓鴻蒙版直接消費現(xiàn)有 PO/MO 文件而不是另起爐灶維護一套新資源。于是我把 Flutter 三方庫 gettext_parser 引到鴻蒙工程里做驗證結(jié)果一個問題接一個問題冒出來文件讀取層要適配、編碼差異要處理、大 PO 文件解析性能不夠、復(fù)數(shù)規(guī)則跟兩側(cè)平臺對不齊。這篇文章就完整記錄這次的適配過程從 PO/MO 格式原理講起到鴻蒙化改造的具體步驟再到高性能多語言資源轉(zhuǎn)換管線的設(shè)計最后附上問題排查速查表。如果你也在做 Flutter 鴻蒙化遷移或者打算在 Flutter 工程里接入 gettext 翻譯生態(tài)這些經(jīng)驗應(yīng)該能幫你省下不少試錯時間。1. 項目背景為什么鴻蒙應(yīng)用還要接 gettext 生態(tài)1.1 存量翻譯資產(chǎn)的價值先說個容易被忽略的事實很多中大型應(yīng)用的多語言資產(chǎn)并不是 Flutter 默認的 ARB 文件而是 gettext 體系的 PO/MO 文件。POPortable Object是給人讀、給版本控制工具 diff 的純文本格式每條翻譯由msgid原文和msgstr譯文組成MOMachine Object則是 PO 編譯后的二進制形態(tài)體積小、讀取快適合丟進生產(chǎn)環(huán)境。這類資產(chǎn)值錢在于幾個特性一是可讀性好翻譯人員用普通文本編輯器就能改git 里哪行文案變了清清楚楚二是工具鏈成熟各類翻譯管理平臺都能直接導(dǎo)入導(dǎo)出 PO三是帶上下文和標記能力msgctxt、fuzzy、obsolete這些標記讓翻譯質(zhì)量管控有據(jù)可查。我接手這個項目時PO 文件已經(jīng)沉淀了四五年里面還有大量經(jīng)過市場驗證的術(shù)語和句式這筆資產(chǎn)遷移到鴻蒙上要是不能用等于從零再來一遍。所以鴻蒙化的第一個結(jié)論就是解析器必須在 Dart 側(cè)實現(xiàn)運行在 Flutter 應(yīng)用的進程內(nèi)而不是依賴系統(tǒng)級 gettext 庫——HarmonyOS 上沒有現(xiàn)成的 gettext 運行時。gettext_parser 這個純 Dart 包正好是干這個的。1.2 gettext_parser 的能力邊界與適配難點在動手前我把 gettext_parser 的能力邊界摸了一遍。它的核心是解析 PO 文本逐條吐出翻譯條目支持多行字符串拼接、轉(zhuǎn)義序列處理、上下文和復(fù)數(shù)原文。這對文本格式覆蓋得不錯但有三件事它不管文件從哪讀、MO 二進制怎么解、解析出來的數(shù)據(jù)怎么變成 Flutter 或鴻蒙的資源格式。這三點恰好是鴻蒙化適配的難點。文件讀取這層最麻煩。gettext_parser 本身不碰dart:io但常規(guī)用法都在外面套一層File(path).readAsString()。PC 上沒問題進了鴻蒙沙箱就有講究應(yīng)用只能訪問自己的filesDir、cacheDir等目錄資產(chǎn)文件要走rootBundle下載的翻譯包要先進沙箱再讀。路徑語義全變了。MO 二進制解析是我后補的。gettext 的 PO 適合人維護但 App 啟動時逐行解析有明顯開銷MO 作為編譯產(chǎn)物在二進制層面更省資源。不過 MO 有端序問題、字符串表偏移問題直接按字節(jié)硬讀很容易踩坑。至于資源轉(zhuǎn)換那更是八仙過海Flutter 用 ARBHarmonyOS 用string.json兩邊對復(fù)數(shù)分類的口徑還不一樣。gettext 的復(fù)數(shù)規(guī)則是數(shù)學(xué)表達式CLDR 的復(fù)數(shù)類別是語義分類兩邊需要專門做一層映射。這塊我后面會細講。1.3 整體改造思路純 Dart 核心 可插拔 IO我最終采用的架構(gòu)是三層分離解析核心層、數(shù)據(jù)源抽象層、資源轉(zhuǎn)換層。解析核心層保持純 Dart不 import 任何dart:io這樣它在構(gòu)建腳本、桌面工具、鴻蒙運行環(huán)境里都能跑。數(shù)據(jù)源抽象層定義一個GetTextSource接口按場景提供不同實現(xiàn)構(gòu)建期用文件系統(tǒng)實現(xiàn)讀磁盤 PO運行期用資產(chǎn)實現(xiàn)走rootBundle單元測試用內(nèi)存實現(xiàn)喂字符串。資源轉(zhuǎn)換層把解析出的條目統(tǒng)一成中間模型再分別輸出 ARB 和 HarmonyOS 的string.json。這樣設(shè)計的好處很明顯構(gòu)建工具和 App 運行時共享同一套解析邏輯不用維護兩份單元測試可以脫離文件系統(tǒng)跑回歸成本低將來如果還要支持 Android 的strings.xml或者 iOS 的strings只需要在轉(zhuǎn)換層加一個輸出器核心代碼一行都不用動。2. 解析器核心邏輯拆解PO/MO 文件到底怎么讀2.1 PO 文本格式與狀態(tài)機解析PO 文件看起來就是一組以msgid開頭的塊中間用空行分隔。實際結(jié)構(gòu)比表面復(fù)雜一段典型的 PO 條目長這樣# 翻譯者注釋 #. 提取的注釋 #: src/page.dart:120 #, fuzzy msgctxt menu_title msgid Open msgid_plural Open items msgstr[0] 打開 msgstr[1] 打開項目#開頭的行是注釋其中#, fuzzy表示這條翻譯還沒確認#~前綴表示條目已廢棄。msgctxt是上下文msgid是單數(shù)原文msgid_plural是復(fù)數(shù)原文msgstr[N]是對應(yīng)的第 N 個譯文。文件頭還有一個msgid 的特殊條目里面存放的是元數(shù)據(jù)包括字符集聲明和Plural-Forms表達式。解析時我用的狀態(tài)機思路逐行掃描維護一個“當(dāng)前條目”和“當(dāng)前字段”的狀態(tài)?？吹絤sgid、msgctxt、msgstr[N]就切換字段看到以引號開頭的行說明是上一個字段的多行續(xù)接拼到當(dāng)前字段末尾遇到空行就把當(dāng)前條目封口并加入結(jié)果列表。字符串還要做反轉(zhuǎn)義\n、\t、\、\\這些都要還原成真實字符。這里有個容易忽略的細節(jié)續(xù)接行不能簡單trim()掉內(nèi)部空格。PO 規(guī)范里字符串內(nèi)部的空格是有意義的只有行首行尾的空白是格式噪音。處理時我會先去掉整行的trim()再用引號配對截出字符串體最后統(tǒng)一反轉(zhuǎn)義。實測不少第三方 PO 文件就是因為某一行多了個尾部空格導(dǎo)致譯文拼接錯位。2.2 MO 二進制格式與端序識別MO 是二進制格式結(jié)構(gòu)比 PO 緊湊得多。文件頭的固定 28 個字節(jié)里最關(guān)鍵的是前 4 個字節(jié)的魔數(shù)小端序是0x950412de大端序是0xde120495。讀到魔數(shù)后要先判斷端序再用對應(yīng)端序去讀后面的字段否則條目數(shù)量會變成天文數(shù)字偏移量也全錯。MO 文件頭字段如下偏移長度字段說明04magic魔數(shù)用于識別文件和端序44revision版本號常見為 084N條目總數(shù)124O原文字符串表的偏移164T譯文字符串表的偏移204S哈希表條目數(shù)0 表示沒有哈希表244H哈希表偏移字符串表是一連串(長度, 偏移)對每對占 8 字節(jié)。注意這里的偏移是相對于整個文件頭的不是相對于字符串表的我第一次實現(xiàn)時就在這栽了跟頭。解析完所有條目后再把偏移和長度指向的字節(jié)用 UTF-8 解碼成字符串。我在 Dart 側(cè)的實現(xiàn)大致長這樣ListMoEntry parseMoBytes(Uint8List data) { final bd ByteData.sublistView(data); final magic bd.getUint32(0, Endian.little); final isBigEndian magic 0x950412de; final isLittleEndian magic 0xde120495; if (!isBigEndian !isLittleEndian) { throw FormatException(無效的 MO 文件魔數(shù)不匹配); } final endian isBigEndian ? Endian.big : Endian.little; final count bd.getUint32(8, endian); final origTable bd.getUint32(12, endian); final transTable bd.getUint32(16, endian); final entries MoEntry[]; for (var i 0; i count; i) { final oLen bd.getUint32(origTable i * 8, endian); final oPtr bd.getUint32(origTable i * 8 4, endian); final tLen bd.getUint32(transTable i * 8, endian); final tPtr bd.getUint32(transTable i * 8 4, endian); if (oPtr oLen data.length || tPtr tLen data.length) { throw FormatException(MO 字符串表越界); } entries.add(MoEntry( utf8.decode(data.sublist(oPtr, oPtr oLen)), utf8.decode(data.sublist(tPtr, tPtr tLen)), )); } return entries; }這里我加了兩個防御一是魔數(shù)不匹配直接拋異常二是讀取字符串前校驗偏移和長度是否越界。MO 文件被截斷或者被錯誤編譯時沒有這兩個檢查會直接拋一個很難看的RangeError有了解讀性更好的異常排查問題能少花一半時間。2.3 復(fù)數(shù)規(guī)則類別的語義映射PO 文件頭的Plural-Forms是一個數(shù)學(xué)表達式例如英文是nplurals2; plural(n ! 1);俄文是nplurals3; plural(n%101 n%100!11 ? 0 : n%102 n%104 (n%10010 || n%10020) ? 1 : 2);。而 Flutter 的 ARB 和 HarmonyOS 的資源文件用的是 CLDR 復(fù)數(shù)類別zero、one、two、few、many、other。這兩者不是一回事gettext 返回的是一個整數(shù)索引第幾個譯文CLDR 返回的是一個語義類別。直接硬映射容易出錯比如俄文的 gettext 索引 0 對應(yīng)one索引 1 對應(yīng)few索引 2 對應(yīng)many但不同語言、不同公式這種對應(yīng)關(guān)系完全不同。我的做法是采樣映射對每個語言取一組有代表性的 n 值0、1、2、3、5、10、21、100 等代入 gettext 的plural表達式得到索引再用intl包判斷同樣的 n 在 CLDR 下屬于哪個類別最后統(tǒng)計出“索引到類別”的映射關(guān)系并緩存。這樣不需要為每種語言硬編碼規(guī)則公式變了也能自動適配。語言族PO 中 nplurals 數(shù)量對應(yīng) CLDR 復(fù)數(shù)類別中文、日文、韓文1other英文、德文、西班牙文2one / other俄文、烏克蘭文3one / few / many / other阿拉伯文6zero / one / two / few / many / other這張表是概念示意實際轉(zhuǎn)換時請務(wù)必用采樣法動態(tài)生成映射別偷懶寫死。3. 鴻蒙化改造實操從依賴引入到構(gòu)建通過3.1 環(huán)境準備與依賴引入策略鴻蒙化第一步不是寫代碼而是確認你的 Flutter 工程確實能構(gòu)建出ohos平臺目錄。我在現(xiàn)有工程里補建了ohos/平臺工程flutter 側(cè)環(huán)境變量指向?qū)?yīng)的鴻蒙 SDK然后跑一次構(gòu)建讓腳手架生成平臺目錄。接下來是關(guān)鍵判斷gettext_parser 是純 Dart 包沒有 Android 的 Kotlin 代碼、沒有 iOS 的 Swift 代碼、沒有 method channel所以它不需要像插件那樣做原生適配。理論上在pubspec.yaml里加一行依賴就能編譯過dependencies: gettext_parser: ^2.0.0但實際我遇到了 SDK 約束問題。這個包的environment聲明要求某個 Dart SDK 版本范圍而鴻蒙側(cè)的 Flutter 版本自帶的 Dart SDK 可能落在范圍之外。遇到這種情況不要急著硬改pubspec.lock更穩(wěn)妥的辦法是把它 fork 一份放到工程的packages/gettext_parser_ohos目錄通過dependency_overrides指向本地路徑順便改掉那些依賴特定 Dart 版本特性的代碼。這樣以后鴻蒙 SDK 升級了你也能控制包的版本行為。3.2 文件讀取適配層設(shè)計純 Dart 包能編譯過只是第一步真正常踩坑的是數(shù)據(jù)從哪來。我在GetTextSource接口上做了三個實現(xiàn)讓解析層完全感知不到平臺差異abstract class GetTextSource { FutureString readPo(String locale); FutureUint8List readMo(String locale); } // 構(gòu)建期/桌面工具用直接讀磁盤 class FileSource implements GetTextSource { final String baseDir; FileSource(this.baseDir); override FutureString readPo(String locale) async { final file File($baseDir/$locale.po); return file.readAsString(); } override FutureUint8List readMo(String locale) async { final file File($baseDir/$locale.mo); return file.readAsBytes(); } } // App 運行期用走 Flutter 資產(chǎn) class AssetSource implements GetTextSource { override FutureString readPo(String locale) async { return rootBundle.loadString(assets/l10n/$locale.po); } override FutureUint8List readMo(String locale) async { final data await rootBundle.load(assets/l10n/$locale.mo); return data.buffer.asUint8List(); } }這個改動打掉了 90% 的鴻蒙適配問題。因為 gettext_parser 本身不讀文件只要外面喂字節(jié)給它它在哪個平臺跑都是一樣的。我的經(jīng)驗是凡是能定義抽象接口的 IO 操作一定要定義接口別讓解析庫直接碰dart:io。這條原則對鴻蒙化尤其重要因為平臺差異幾乎全部集中在 IO 邊界上。3.3 沙箱路徑與資源預(yù)加載的處理如果把 PO/MO 文件打進安裝包那運行期直接用AssetSource就好assets/l10n/目錄下的文件在鴻蒙上會隨 FLutter 資產(chǎn)一起打包。但有些場景需要動態(tài)更新翻譯例如從服務(wù)端拉取最新的 PO 文件。這時候問題來了下載文件寫到哪里鴻蒙應(yīng)用沙箱里可以寫入的目錄是有限的。我們一般用路徑提供器拿到filesDir或cacheDir然后把下載的 PO 文件寫到那里。注意cacheDir里的文件隨時可能被系統(tǒng)清理適合放臨時緩存要長期保留的翻譯文件放filesDir更穩(wěn)。千萬別嘗試往安裝目錄或者外部公共目錄寫權(quán)限和路徑都存在不確定性。文件寫好后還要考慮加載時機。幾千條文案的 PO 文件解析耗時在百毫秒級如果 APP 啟動第一幀就同步解析用戶會明顯感覺到卡頓。我做了兩級緩解啟動時用Isolate.run丟到后臺 isolate 解析解析結(jié)果緩存到內(nèi)存如果文件太大、啟動階段實在來不及就先只解析當(dāng)前語言其余語言等用戶切換時再懶加載。3.4 構(gòu)建配置與平臺工程注冊關(guān)于ohos/平臺的構(gòu)建配置有三個點值得單獨說。第一確保pubspec.yaml的 assets 聲明里包含了 PO/MO 文件路徑。只在目錄里放了文件但沒有聲明構(gòu)建時會被靜默丟棄。第二純 Dart 包不需要在 ohos 平臺目錄里注冊任何東西但如果你的工程里還有其他依賴是帶原生代碼的 flutter 插件它們必須有對應(yīng)的 ohos 適配版本否則整條構(gòu)建鏈會掛在依賴解析上。第三HarmonyOS 側(cè)的網(wǎng)絡(luò)權(quán)限默認不開如果運行期要拉取翻譯文件記得在ohos工程相應(yīng)的配置文件里聲明網(wǎng)絡(luò)權(quán)限只在本地解析則無需任何額外權(quán)限。構(gòu)建跑通以后我的運行期代碼路徑是這樣的優(yōu)先嘗試讀取 MO二進制的加載和解析都更快文件不存在再退回讀 PO——完全沿用 gettext 生態(tài)的慣例把 MO 當(dāng)生產(chǎn)格式PO 當(dāng)維護格式。4. 高性能多語言資源轉(zhuǎn)換管線4.1 轉(zhuǎn)換鏈路PO/MO → 中間模型 → ARB / string.json轉(zhuǎn)換管線是我這套方案里最實用的部分。它的目標是一份 PO/MO 資產(chǎn)自動產(chǎn)出 Flutter 工程用的 ARB 和鴻蒙工程用的string.json。鏈路分三段。第一段是輸入規(guī)范化PO 文本或 MO 字節(jié)統(tǒng)一解析成PoEntry列表。第二段是中間模型把條目去重、過濾掉fuzzy和obsolete并解析出復(fù)數(shù)類別映射得到干凈的“key 到譯文”數(shù)據(jù)。第三段是輸出按目標平臺的格式序列化。過濾邏輯很關(guān)鍵我單獨摘出來MapString, String toSimpleMap(ListPoEntry entries) { final map String, String{}; for (final entry in entries) { if (entry.obsolete) continue; // 廢棄條目不要 if (entry.fuzzy) continue; // 未確認翻譯不要 if (entry.msgid.isEmpty) continue; // 跳過頭部元數(shù)據(jù) final value entry.msgstr.isNotEmpty ? entry.msgstr.first : entry.msgid; map[entry.msgid] value.isEmpty ? entry.msgid : value; } return map; }譯文為空時回退到原文保證 UI 上不會出現(xiàn)空白標簽。輸出 ARB 時把開頭的元數(shù)據(jù)鍵補上輸出鴻蒙資源時轉(zhuǎn)成下面這種結(jié)構(gòu){ string: [ { name: hello, value: 你好 } ], plural: [ { name: messageCount, value: [ { quantity: one, value: %d 條消息 }, { quantity: other, value: %d 條消息 } ] } ] }這里要特別留意不同 HarmonyOS API 版本對資源文件的組織方式可能有差異有的版本把string和plural放在同一個 JSON 的不同數(shù)組里有的版本拆成獨立文件。我建議在轉(zhuǎn)換器里把“是否輸出 plural 數(shù)組”做成開關(guān)按目標 API 版本配置。4.2 性能調(diào)優(yōu)分檔緩存、流式解析與并發(fā)轉(zhuǎn)換“高性能”不是堆出來的形容詞落到具體指標上我關(guān)注的是解析耗時和內(nèi)存峰值。剛開始直接File.readAsString再逐行解析一個 24 MB 的大 PO 文件能把內(nèi)存頂?shù)?200 MB 以上App 必崩。后來做了三件事把它壓下來。第一解析結(jié)果分檔緩存。解析過的條目存在內(nèi)存 Map 里再次請求同一個語言直接命中不重復(fù)解析。第二盡量用流式接口。gettext_parser 本身支持按塊吐出條目用await for消費而不是攢成一個 List內(nèi)存占用能降一半。第三大文件丟給 isolate。Isolate.run(() parseAndConvert(...))可以在后臺線程完成解析和序列化避免 jank。我這邊在中端測試機上測的一組數(shù)據(jù)僅供參考文件大小 / 條目數(shù)解析方式耗時內(nèi)存峰值2 MB / 4800 條全量讀入 狀態(tài)機約 130 ms約 24 MB2 MB / 4800 條流式分塊解析約 95 ms約 12 MB24 MB / 53000 條全量讀入約 2.8 s約 210 MB24 MB / 53000 條isolate 分檔緩存約 1.1 s約 60 MB還有一個構(gòu)建期的小技巧轉(zhuǎn)換工具本身用dart run執(zhí)行多個語言文件可以并行轉(zhuǎn)換每個語言一個 isolate總耗時能進一步壓縮。因為語言之間沒有依賴并行是天然安全的。4.3 輸出資源的一致性校驗自動化轉(zhuǎn)換最怕的是“轉(zhuǎn)出來了但轉(zhuǎn)錯了”。我加了三個校驗步驟每次轉(zhuǎn)換后自動執(zhí)行。第一個是鍵一致性檢查把基準語言一般是英文的 key 集合和各語言比對報告缺失和多余。多余的 key 通常意味著 PO 文件里殘留了廢棄條目沒清干凈。第二個是占位符檢查用正則提取%s、%d、{name}這類占位符比對原文和譯文的集合是否一致不一致的條目直接標紅。這個檢查救過我多次——譯者把%s打成了%S真機上就跑出奇怪文案。第三個是復(fù)數(shù)形式數(shù)量檢查對比Plural-Forms聲明和實際msgstr[n]條目數(shù)數(shù)量對不上說明文件本身損壞。5. 常見問題與排查技巧實錄5.1 編碼與 BOM 相關(guān)的三個坑第一坑UTF-8 BOM。有的 Windows 端翻譯工具會往 PO 文件頭塞 BOMEF BB BFDart 的utf8.decode遇到 BOM 會把\uFEFF當(dāng)作第一個字符帶進解析結(jié)果。處理辦法是讀取后先檢測并剝離 BOM 再喂給解析器。第二坑字符集聲明和實際編碼不符。PO 文件頭的Content-Type可能寫著charsetUTF-8但實際文件是 Latin-1 或 GBK 編碼。這種情況在從老系統(tǒng)遷移的 PO 里不少見。我在數(shù)據(jù)源層做了個預(yù)檢讀前 64 字節(jié)嘗試檢測編碼如果檢測結(jié)果不是 UTF-8就先用對應(yīng)字符集轉(zhuǎn)成 UTF-8 再解析。Dart 側(cè)沒有內(nèi)置全套字符集轉(zhuǎn)換需要引入轉(zhuǎn)換類庫或者更穩(wěn)妥的辦法是讓翻譯工具重新導(dǎo)出一次 UTF-8 版本——我通常選后者因為歷史編碼文件里往往混著損壞的字節(jié)硬轉(zhuǎn)不如重導(dǎo)。第三坑字符串里的裸換行。PO 規(guī)范要求長字符串用引號續(xù)接但也有不守規(guī)矩的文件直接在msgstr里塞了裸換行導(dǎo)致狀態(tài)機誤判條目結(jié)束。我的兜底策略是解析出錯時記錄行號而不是直接拋異常終止整個文件把單條錯誤隔離掉保證其余條目還能用。5.2 復(fù)數(shù)規(guī)則與占位符不匹配復(fù)數(shù)這塊最常見的問題是只取了msgstr[0]就當(dāng)成單數(shù)用。后果是俄文、阿拉伯文這類多復(fù)數(shù)形態(tài)的語言界面上一部分場景永遠顯示默認格式。我的采樣映射方案解決了索引到 CLDR 類別的換算但還有一個前提PO 文件里必須真的有完整復(fù)數(shù)條目。如果原文里只有msgstr[0]那再怎么映射也只有一種形態(tài)這種情況要回到翻譯流程去補齊。占位符問題則是另一類重災(zāi)區(qū)。gettext 傳統(tǒng)上是%s、%d風(fēng)格而 ARB 喜歡{name}命名風(fēng)格HarmonyOS 資源又常同時支持%s和{name}。我見過最慘烈的案例是%1$s這種帶位置參數(shù)的占位符被無腦替換成{1}結(jié)果真機上直接顯示花括號。我的處理策略是轉(zhuǎn)換時先按序把%s、%d映射到{arg0}、{arg1}再在目標平臺格式化處按序替換回去。新加的文案則一律要求譯者使用命名占位符從源頭消滅歧義。5.3 大文件解析卡頓與內(nèi)存飆升小 PO 文件隨便解析都沒問題一旦翻譯條目超過兩三萬問題就暴露了。卡頓的根源通常不是 CPU而是字符串頻繁拼接和中間 List 積壓。分析下來占內(nèi)存大頭的往往是readAsString那把整個文件一次性讀進來的字符串對象加上逐條解析時臨時生成的中間字符串兩頭一夾內(nèi)存就上去了。我的解法有兩層。運行時解析走流式不要把整個 PO 內(nèi)容變成一個超長 String而是分塊讀、分塊解析塊與塊之間共享狀態(tài)機狀態(tài)。構(gòu)建期工具則更簡單粗暴把大的 PO 按語言拆成多個獨立文件并行解析。真到了單文件幾十 MB 的規(guī)模配合Isolate.run和結(jié)果緩存內(nèi)存峰值能壓到原來的四分之一左右。5.4 我在實操中總結(jié)的三個小原則適配做下來沉淀出三條經(jīng)驗比任何具體代碼都值錢。第一解析庫必須保持純 Dart所有 IO 都要通過抽象接口注入。這不是潔癖而是鴻蒙、Web、桌面、測試環(huán)境對文件訪問的語義差異太大靠if (Platform.isXxx)打補丁遲早翻車。第二轉(zhuǎn)換工具的校驗邏輯要比功能代碼寫得早。多語言資源一旦出問題用戶看到的是亂碼和錯位反饋鏈路很長靠人工排查成本極高校驗必須在構(gòu)建階段自動完成。第三歸檔時把 PO 文件和轉(zhuǎn)換腳本放同一個倉庫做到“改完 PO跑一下腳本資源就齊了”。我后來把這條鏈路接進了 CI每次合并前自動跑一遍轉(zhuǎn)換和校驗已經(jīng)有兩次在發(fā)版前攔下了占位符不一致的問題。這些經(jīng)驗對任何涉及多語言資源遷移的項目都適用不只是鴻蒙這一個場景。