項(xiàng)目標(biāo)題將 USTRUCT 類型的實(shí)例對象轉(zhuǎn)換成對應(yīng)的 JSON 字符串格式服務(wù)端要做一份配置下發(fā)接口要求客戶端把玩家當(dāng)前狀態(tài)打包成 JSON 字符串 POST 上去。我第一次圖省事用FString::Printf一段一段手工拼 JSON十幾個(gè)字段拼到一半就分不清誰是誰了該轉(zhuǎn)義的引號、換行也鬧出過幾次解析失敗。換成 USTRUCT 加FJsonObjectConverter之后幾十行手拼代碼縮成了兩三行字段誰有誰沒有、什么類型什么名字全部由反射系統(tǒng)統(tǒng)一處理問題一次性清干凈。這篇內(nèi)容講的就是這件事在 Unreal Engine 里把一個(gè)聲明了 USTRUCT 的結(jié)構(gòu)體實(shí)例按照字段定義轉(zhuǎn)換成 JSON 字符串順帶也講清楚反向的 JSON 字符串還原結(jié)構(gòu)體。文章會覆蓋原理、模塊依賴、基礎(chǔ)寫法、字段映射、復(fù)雜類型處理、性能邊界和常見坑。適合正在做網(wǎng)絡(luò)對接、存檔讀寫、調(diào)試工具或者單純想把結(jié)構(gòu)體快速導(dǎo)出去給別的程序用的開發(fā)者。不管你是剛接觸 JSON 轉(zhuǎn)換還是已經(jīng)踩過不少坑都能在里面找到能直接拿去用的方案。1. 項(xiàng)目拆解USTRUCT轉(zhuǎn)JSON到底在解決什么問題1.1 標(biāo)題背后的核心需求標(biāo)題里的兩個(gè)關(guān)鍵詞非常明確一個(gè)是 USTRUCT一個(gè)是 JSON。USTRUCT 是 Unreal Engine 中用于聲明“帶反射信息結(jié)構(gòu)體”的宏。所謂反射就是這個(gè)結(jié)構(gòu)體運(yùn)行時(shí)能告訴引擎自己有哪些字段、字段是什么類型、字段名是什么。JSON 這端則是一種跨語言、跨平臺、純文本的數(shù)據(jù)交換格式廣泛用于 Web API、配置文件、日志上報(bào)、編輯器導(dǎo)出等場景。把兩者結(jié)合起來本質(zhì)就是讓 UE 的 C 結(jié)構(gòu)體能以 JSON 文本形式“走出引擎”被服務(wù)端、網(wǎng)頁端、Python 腳本或者其他任何支持 JSON 的系統(tǒng)讀取。這個(gè)需求的背后通常不是“想用 JSON”而是“要和外界交換數(shù)據(jù)”。自己項(xiàng)目內(nèi)部用結(jié)構(gòu)體傳參很舒服可一旦數(shù)據(jù)要發(fā)到 HTTP 接口、寫進(jìn)人類可讀的配置文件、或者導(dǎo)出給策劃看就必須轉(zhuǎn)成文本。JSON 只是最通用、最不容易出錯(cuò)的文本載體。1.2 典型應(yīng)用場景實(shí)際項(xiàng)目里這個(gè)轉(zhuǎn)換能力最常見的使用場景有四類。第一類是網(wǎng)絡(luò)消息體。客戶端和服務(wù)端之間用 HTTP 或者 WebSocket 通信消息體按 JSON 組織。客戶端把 USTRUCT 代表的玩家信息、戰(zhàn)績、背包數(shù)據(jù)一次性轉(zhuǎn)成 JSON 發(fā)送服務(wù)端解析后入庫。第二類是本地配置和存檔。把結(jié)構(gòu)體實(shí)例保存為 JSON 文件下次啟動讀回來。比起自己定義二進(jìn)制格式JSON 文件可以直接打開檢查出問題一眼就能看出來。第三類是調(diào)試輸出。結(jié)構(gòu)體里字段多用UE_LOG一個(gè)個(gè)打印太啰嗦。直接轉(zhuǎn)換成 JSON 字符串打一條日志字段名和值都看得清清楚楚。第四類是編輯器工具和外部程序交換。比如寫編輯器插件批量導(dǎo)資源信息導(dǎo)出的就可以是 JSON 數(shù)組文件。1.3 能做什么、不能做什么這套做法能覆蓋絕大多數(shù)普通結(jié)構(gòu)體整數(shù)、浮點(diǎn)數(shù)、布爾、字符串、枚舉、數(shù)組、嵌套結(jié)構(gòu)體以及一部分容器類型。但它不是萬能的。TMap、TSet這類容器的支持在不同引擎版本里差異很大FText導(dǎo)出后是一個(gè)嵌套對象而不僅僅是文本沒有UPROPERTY修飾的字段不參與轉(zhuǎn)換反射系統(tǒng)看不到它。這些邊界不是一個(gè)“轉(zhuǎn)換函數(shù)”能包辦的需要寫的人在代碼里做好約定。還有個(gè)容易搞混的點(diǎn)USTRUCT 和 UObject 是兩回事。USTRUCT 是輕量的值類型可以用StaticStruct()拿到反射定義UObject 是引擎對象序列化走的是另一套UObjectToJsonObjectString之類的路徑。標(biāo)題里明確說“USTRUCT 類型的實(shí)例對象”所以本文聚焦在結(jié)構(gòu)體上。2. 前置準(zhǔn)備與序列化原理2.1 反射系統(tǒng)為什么 USTRUCT 是前提先理解一個(gè)關(guān)鍵點(diǎn)UE 里的 JSON 轉(zhuǎn)換器不是靠猜字段來做序列化的它靠的是反射元數(shù)據(jù)。當(dāng)你寫下USTRUCT(BlueprintType)并給字段加上UPROPERTY后UHTUnreal Header Tool會在編譯期生成這個(gè)結(jié)構(gòu)體的反射描述。運(yùn)行時(shí)FJsonObjectConverter會通過TFieldIteratorFProperty遍歷結(jié)構(gòu)體的所有反射屬性逐個(gè)讀取當(dāng)前實(shí)例里對應(yīng)字段的值再根據(jù)字段類型決定寫入 JSON 對象的方式。所以有三條硬性規(guī)則結(jié)構(gòu)體必須用USTRUCT聲明并包含GENERATED_BODY()。想導(dǎo)出到 JSON 的字段必須用UPROPERTY修飾。字段類型必須在轉(zhuǎn)換器的支持范圍內(nèi)。我見過不少新人把USTRUCT當(dāng)普通 C 結(jié)構(gòu)體用字段全裸奔結(jié)果轉(zhuǎn)換函數(shù)返回空對象原因就是反射系統(tǒng)根本看不到這些裸字段。2.2 FJsonObjectConverter 與 FJsonSerializer 的分工UE 的 JSON 體系里有兩個(gè)核心工具很多人會混淆。FJsonObjectConverter負(fù)責(zé)統(tǒng)一“內(nèi)存對象”和“FJsonObject”之間的轉(zhuǎn)換。它做的事情是把 USTRUCT 實(shí)例里的每個(gè)字段映射成FJsonValue節(jié)點(diǎn)再塞進(jìn)一個(gè)TSharedPtrFJsonObject。FJsonSerializer負(fù)責(zé)“FJsonObject”和“文本 JSON”之間的互相轉(zhuǎn)換。它把一個(gè)樹形的 JSON 對象序列化成字符串或者從字符串解析出樹形對象。這里有個(gè)非常好的中間層思路當(dāng)你只需要“USTRUCT 轉(zhuǎn)字符串”時(shí)可以一步到位調(diào)用現(xiàn)成接口但當(dāng)你想在序列化前后修改字段、加字段、刪字段時(shí)就應(yīng)該先轉(zhuǎn)成FJsonObject改完再序列化。這個(gè)中間層也是后面做字段映射、自定義格式的入口。2.3 工程模塊依賴設(shè)置寫代碼之前先確認(rèn)工程模塊引用了 JSON 相關(guān)模塊。在項(xiàng)目的.Build.cs文件里需要添加依賴PublicDependencyModuleNames.AddRange(new string[] { Core, CoreUObject, Engine, Json, JsonUtilities });Json是核心模塊JsonUtilities提供了一些封裝工具舊版本工程尤其常見。如果只用到FJsonObjectConverter和FJsonSerializer一般Json模塊就夠但為了保險(xiǎn)我通常兩個(gè)都加。編寫代碼時(shí)需要包含頭文件#include JsonObjectConverter.h #include Dom/JsonObject.h #include Serialization/JsonSerializer.h如果編譯報(bào)找不到JsonObjectConverter.h先別查頭文件路徑回去檢查.Build.cs是否真的加了模塊。3. 基礎(chǔ)實(shí)操一行代碼完成USTRUCT轉(zhuǎn)JSON字符串3.1 定義一個(gè)可轉(zhuǎn)換的USTRUCT以一個(gè)游戲玩家檔案為例USTRUCT(BlueprintType) struct FPlayerProfile { GENERATED_BODY() UPROPERTY(BlueprintReadOnly) FString PlayerName; UPROPERTY(BlueprintReadOnly) int32 Level 1; UPROPERTY(BlueprintReadOnly) float Score 0.0f; UPROPERTY(BlueprintReadOnly) bool bIsVIP false; UPROPERTY(BlueprintReadOnly) TArrayFString Achievements; };必須注意字段上的UPROPERTY不是可有可無。如果一個(gè)字段想不出現(xiàn)在 JSON 里要么不寫UPROPERTY要么在結(jié)構(gòu)體上用UPROPERTY(Transient)標(biāo)記成瞬態(tài)字段然后在轉(zhuǎn)換時(shí)配合SkipFlags排除。3.2 標(biāo)準(zhǔn)轉(zhuǎn)換寫法聲明一個(gè)實(shí)例并填充數(shù)據(jù)然后調(diào)用轉(zhuǎn)換接口FPlayerProfile Profile; Profile.PlayerName TEXT(Ada); Profile.Level 42; Profile.Score 99.5f; Profile.bIsVIP true; Profile.Achievements { TEXT(FirstBlood), TEXT(TankKiller) }; FString OutJson; const bool bSuccess FJsonObjectConverter::UStructToJsonObjectString( FPlayerProfile::StaticStruct(), Profile, OutJson ); if (bSuccess) { UE_LOG(LogTemp, Log, TEXT(%s), *OutJson); }輸出結(jié)果是{PlayerName:Ada,Level:42,Score:99.5,bIsVIP:true,Achievements:[FirstBlood,TankKiller]}這一步就是標(biāo)題說的核心需求。FPlayerProfile::StaticStruct()拿到結(jié)構(gòu)體的反射定義Profile是實(shí)例內(nèi)存地址OutJson接收結(jié)果。有一點(diǎn)要提前打預(yù)防針不同引擎版本里UStructToJsonObjectString的參數(shù)表不完全一樣。比如 UE4.27 和 UE5.3 在“是否支持縮進(jìn)參數(shù)”“是否支持自定義序列化器”上就有差異。最穩(wěn)妥的辦法是在編輯器里對著JsonObjectConverter.h的聲明確認(rèn)參數(shù)順序。本文示例方案是最常用的一組參數(shù)核心用法在所有支持FJsonObjectConverter的版本里都成立。3.3 反序列化從JSON字符串還原USTRUCT轉(zhuǎn)換是雙向的光會導(dǎo)出不夠還要能讀回來。FPlayerProfile Restored; const bool bParseSuccess FJsonObjectConverter::JsonObjectStringToUStruct( OutJson, FPlayerProfile::StaticStruct(), Restored ); if (bParseSuccess) { // Restored.PlayerName TEXT(Ada) }JsonObjectStringToUStruct是字符串入口內(nèi)部會先調(diào)用FJsonSerializer::Deserialize解析成FJsonObject再通過JsonObjectToUStruct寫回結(jié)構(gòu)體。這里有一個(gè)很常見的需求服務(wù)端返回的 JSON 里可能有額外字段而結(jié)構(gòu)體里并沒有對應(yīng)屬性。此時(shí)新版引擎的JsonObjectToUStruct提供了不允許“部分字段缺失”的嚴(yán)格模式參數(shù)。常規(guī)場景不啟用嚴(yán)格模式解析器會自動跳過結(jié)構(gòu)體里沒有的字段這樣前后端字段擴(kuò)展時(shí)不會因?yàn)槎嘁粋€(gè)字段就把整段解析搞掛。3.4 CheckFlags 與 SkipFlags 這兩個(gè)參數(shù)UStructToJsonObjectString參數(shù)里有一對很容易被忽略的int64標(biāo)記位CheckFlags和SkipFlags。CheckFlags表示只導(dǎo)出“包含這些標(biāo)記”的屬性。比如傳入CPF_Edit就只導(dǎo)出標(biāo)了Edit的屬性平時(shí)基本用不上。SkipFlags表示跳過“包含這些標(biāo)記”的屬性。這個(gè)才是真正常用的。舉例來說如果一個(gè)字段加了Transient表示它不需要持久化UPROPERTY(Transient) FString SessionToken;轉(zhuǎn)換時(shí)不想帶上它就可以這樣FJsonObjectConverter::UStructToJsonObjectString( FPlayerProfile::StaticStruct(), Profile, OutJson, 0, CPF_Transient );我還會把CPF_Deprecated也放進(jìn)SkipFlags把標(biāo)記了廢棄的字段一起過濾掉。這個(gè)參數(shù)在處理老結(jié)構(gòu)體、兼容歷史字段時(shí)非常有用比改結(jié)構(gòu)體定義要溫柔得多。4. 實(shí)用細(xì)節(jié)字段名映射與復(fù)雜類型處理4.1 字段名默認(rèn)規(guī)則與坑UE 的 JSON 轉(zhuǎn)換器默認(rèn)輸出的是UPROPERTY原本的名字。也就是說C 里叫PlayerNameJSON 里就是PlayerName不會自動轉(zhuǎn)成playerName或player_name。這在實(shí)際對接外部系統(tǒng)時(shí)經(jīng)常出問題。服務(wù)端接口可能是player_name可能是playerName甚至可能是全小寫。如果為每個(gè)字段改名最簡單的做法是先轉(zhuǎn)成FJsonObject再在對象層做改名映射TSharedPtrFJsonObject RootObject MakeSharedFJsonObject(); FJsonObjectConverter::UStructToJsonObject( FPlayerProfile::StaticStruct(), Profile, RootObject.ToSharedRef(), 0, 0 ); // 把 PlayerName 改成 player_name FString Value RootObject-GetStringField(TEXT(PlayerName)); RootObject-RemoveField(TEXT(PlayerName)); RootObject-SetStringField(TEXT(player_name), Value);改完之后再序列化FString OutJson; TSharedRefTJsonWriterTCHAR Writer TJsonWriterFactoryTCHAR::Create(OutJson); FJsonSerializer::Serialize(RootObject.ToSharedRef(), Writer);這個(gè)做法的好處是把“協(xié)議字段名”和“C字段名”徹底解耦。我自己的項(xiàng)目里會把映射關(guān)系集中放一張TMapFString, FString配置表后端改協(xié)議名時(shí)只改配置不動結(jié)構(gòu)體代碼。4.2 布爾字段的 b 前綴引發(fā)的麻煩UE 的命名規(guī)范是布爾字段加b前綴例如bIsVIP。轉(zhuǎn)換器導(dǎo)出時(shí)也原樣帶出去JSON 里就出現(xiàn)了bIsVIP:true。外部接口通常不喜歡這個(gè)b。處理方式和字段改名一樣在FJsonObject中間層把bIsVIP改成is_vip或者isVip。也可以從結(jié)構(gòu)體設(shè)計(jì)層面規(guī)避。如果這個(gè)結(jié)構(gòu)體只是內(nèi)部邏輯使用的那就保留b前綴如果是專門為網(wǎng)絡(luò)協(xié)議建的傳輸 DTO可以故意給字段起名時(shí)不帶b比如就叫IsVIP不過這樣會犧牲一點(diǎn) UE 命名風(fēng)格的一致性。在這個(gè)問題上沒有絕對正確答案團(tuán)隊(duì)約定一致最重要。4.3 嵌套結(jié)構(gòu)體、數(shù)組、TArray 與枚舉嵌套的 USTRUCT 會被自動展開成 JSON 對象不需要額外處理USTRUCT(BlueprintType) struct FPlayerProfile { GENERATED_BODY() UPROPERTY(BlueprintReadOnly) FEquipment Equip; };轉(zhuǎn)換結(jié)果里的Equip會是一個(gè)完整的 JSON 對象等價(jià)于內(nèi)嵌結(jié)構(gòu)體的字段集合。TArray序列化成 JSON 數(shù)組里面的元素可以是基礎(chǔ)類型也可以是嵌套結(jié)構(gòu)體轉(zhuǎn)換器都會遞歸處理。枚舉是很多團(tuán)隊(duì)栽過跟頭的地方。不同引擎版本對枚舉的序列化方式不一樣有的導(dǎo)成數(shù)字有的導(dǎo)成字符串名稱。如果對接的服務(wù)端對枚舉類型有嚴(yán)格要求我建議不要依賴轉(zhuǎn)換器的默認(rèn)行為要么在結(jié)構(gòu)體里單獨(dú)用一個(gè)int32存枚舉整數(shù)值要么在FJsonObject中間層手動讀取枚舉名并寫入字符串字段。容器類型里TMap是最需要小心的。舊版引擎對TMap的支持不穩(wěn)定部分版本直接不支持新版本對TMapFString, T這類“字符串鍵”的支持相對好但整數(shù)鍵、結(jié)構(gòu)體鍵會出各種怪問題。常規(guī)建議是網(wǎng)絡(luò)對接用的結(jié)構(gòu)體盡量避免TMap改成TArray加“Key、Value”成對字段。這樣無論引擎版本怎么變序列化結(jié)果都是穩(wěn)定的。4.4 FText、軟引用等特殊類型注意FText在 UE 里是本地化文本內(nèi)部結(jié)構(gòu)遠(yuǎn)比FString復(fù)雜。JSON 轉(zhuǎn)換時(shí)它會被導(dǎo)成一個(gè)帶culture、text、key等字段的嵌套對象而不是一個(gè)簡單的字符串。如果服務(wù)端不關(guān)心本地化只是想要一個(gè)字符串請直接用FString類型。FSoftObjectPath、TSoftClassPtr、TSubclassOf這些資源引用類型轉(zhuǎn)換器導(dǎo)出的通常是對象路徑字符串。反序列化時(shí)能否真正加載出對象取決于項(xiàng)目資源和引擎行為不要指望 JSON 一解析完就有可用的對象指針。5. 性能邊界與更成熟的設(shè)計(jì)5.1 別在 Tick 里高頻轉(zhuǎn)換FJsonObjectConverter 用的是反射遍歷雖然有不錯(cuò)的優(yōu)化但每次轉(zhuǎn)換都會創(chuàng)建FJsonObject樹、動態(tài)分配節(jié)點(diǎn)、生成字符串。在開發(fā)構(gòu)建下這個(gè)成本會明顯放大如果放在Tick里對幾百個(gè)對象每幀轉(zhuǎn)換一次很快就能看到主線程卡頓。我的經(jīng)驗(yàn)法則是低頻任務(wù)每秒一次、手動觸發(fā)、存檔、發(fā)送消息隨便用。高頻任務(wù)每幀、每幾百毫秒輪詢先考慮做快照避免直接持有游戲線程上的大結(jié)構(gòu)體。萬級以上對象的批量轉(zhuǎn)換優(yōu)先丟到異步線程轉(zhuǎn)換完再回到游戲線程處理結(jié)果。還有一個(gè)實(shí)用技巧如果同一份結(jié)構(gòu)體在短時(shí)間內(nèi)需要多次轉(zhuǎn) JSON可以在字段不變時(shí)緩存上一次的結(jié)果字符串減少重復(fù)反射遍歷。5.2 用 FJsonObject 中間層做高級操作前面提到過UStructToJsonObjectString是為了方便的一次性封裝真正靈活的是先轉(zhuǎn)FJsonObject再操作。一個(gè)典型的例子是在導(dǎo)出前給根對象追加一個(gè)公共字段TSharedPtrFJsonObject RootObject MakeSharedFJsonObject(); FJsonObjectConverter::UStructToJsonObject( FPlayerProfile::StaticStruct(), Profile, RootObject.ToSharedRef(), 0, 0 ); RootObject-SetStringField(TEXT(client_version), TEXT(1.8.5)); RootObject-SetNumberField(TEXT(timestamp), FDateTime::UtcNow().ToUnixTimestamp());還可以把一個(gè)結(jié)構(gòu)體塞進(jìn)另一個(gè)結(jié)構(gòu)體作為子對象或者把整個(gè)對象丟進(jìn)數(shù)組。這些操作在純字符串層面幾乎沒法做但在FJsonObject樹形結(jié)構(gòu)上就是幾個(gè)方法調(diào)用的事。5.3 不要依賴字段順序很多人的直覺是結(jié)構(gòu)體字段按定義順序?qū)С鯦SON 里也是按這個(gè)順序顯示。實(shí)際上FJsonObject內(nèi)部用的是映射結(jié)構(gòu)存儲字段序列化輸出的字段順序并不保證和結(jié)構(gòu)體定義順序一致在不同引擎版本、不同編譯配置下都可能變化。這個(gè)排序的不確定性在對接時(shí)千萬不要設(shè)為前提。JSON 格式本身就不該依賴字段順序服務(wù)端、腳本、測試工具都應(yīng)該按鍵名取字段。如果某個(gè)場景真的必須固定順序比如要做文件簽名校驗(yàn)就需要完全繞開FJsonObject直接用手寫TJsonWriter的方式生成字符串TSharedRefTJsonWriterTCHAR Writer TJsonWriterFactoryTCHAR::Create(OutJson); Writer-WriteObjectStart(); Writer-WriteValue(TEXT(PlayerName), Profile.PlayerName); Writer-WriteValue(TEXT(Level), Profile.Level); Writer-WriteObjectEnd(); Writer-Close();這樣輸出順序完全由代碼控制不會受映射結(jié)構(gòu)干擾。代價(jià)是每個(gè)字段都要手寫適合少量、穩(wěn)定的場景。6. 問題排查與實(shí)操速查6.1 常見問題速查表我把實(shí)際開發(fā)中遇到最多的問題整理成一張表覆蓋率和命中率都非常高?，F(xiàn)象可能原因解決方案輸出{}或缺失字段字段沒加UPROPERTY給字段補(bǔ)上UPROPERTY輸出{}且完全不報(bào)錯(cuò)結(jié)構(gòu)體沒有GENERATED_BODY()或宏寫錯(cuò)檢查USTRUCT定義重新生成頭文件編譯找不到JsonObjectConverter.h模塊依賴沒加Json在.Build.cs添加Json和JsonUtilities布爾導(dǎo)出帶b前綴UE 字段命名規(guī)范導(dǎo)致在FJsonObject中間層改名或定義傳輸 DTO 時(shí)不用b前綴JSON 字段順序亂FJsonObject內(nèi)部是映射結(jié)構(gòu)后端按鍵名取值固定順序請手寫 Writer反序列化返回 false但 JSON 看起來正常字段類型不匹配或啟用了嚴(yán)格模式打印 JSON 核對類型關(guān)閉嚴(yán)格模式使用寬容解析枚舉導(dǎo)出成數(shù)字/字符串不符合預(yù)期不同版本默認(rèn)行為不同用int32手動存枚舉或中間層手動改字段TMap轉(zhuǎn)換報(bào)錯(cuò)或結(jié)果不對舊引擎對容器支持有限改用TArrayFKeyValuePair或自定義序列化FText導(dǎo)成一大串嵌套對象FText內(nèi)部結(jié)構(gòu)特殊傳輸層改用FString6.2 版本差異自查方法Unreal 的 JSON 轉(zhuǎn)換接口在 4.x 和 5.x 之間經(jīng)歷過不少調(diào)整。與其記我寫的某一版參數(shù)不如掌握一個(gè)自查方法打開引擎源碼目錄找到JsonObjectConverter.h直接看當(dāng)前版本里UStructToJsonObjectString和JsonObjectStringToUStruct的完整聲明。版本差異集中在幾個(gè)地方FieldToPropertyMap參數(shù)改名或刪除。是否支持縮進(jìn)參數(shù)Indent。是否支持自定義序列化器TCustomJsonSerializationMap。反序列化時(shí)是否允許部分字段缺失。遇到參數(shù)不匹配的編譯錯(cuò)誤不要硬套老代碼優(yōu)先去看當(dāng)前引擎的頭文件注釋那里才是最新、最準(zhǔn)確的行為說明。這篇內(nèi)容看起來是講一個(gè)轉(zhuǎn)換函數(shù)實(shí)際上是把 UE 反射序列化這條鏈路完整走了一遍。我個(gè)人在實(shí)際項(xiàng)目維護(hù)中最深的一個(gè)體會是與其讓結(jié)構(gòu)體字段直接暴露給外部協(xié)議不如在FJsonObject層面做一層命名映射和字段過濾把協(xié)議變化隔離在轉(zhuǎn)換模塊內(nèi)部。這樣后端改一次字段名、加一次字段類型改動范圍都只限于那個(gè)轉(zhuǎn)換模塊而不會波及整個(gè)游戲邏輯。如果你也在長期對接外部系統(tǒng)這個(gè)思路值得盡早落地。