99%的C#項目都在用同一行代碼埋雷：JsonSerializer.Deserialize(json)。這行代碼背后藏著.NET生態(tài)最大的技術(shù)債務(wù)——反射（reflection，運行時類型檢查機制）驅(qū)動的隱式反序列化。作者Louis Pilfold在文中算了一筆賬：一個中等規(guī)模的微服務(wù)，啟動時要掃描上千個POCO屬性，內(nèi)存里堆滿臨時字符串，CPU在反射調(diào)用中反復(fù)橫跳。

更隱蔽的是類型安全幻覺。你以為public int Id { get; set; }保證了Id一定是整數(shù)？JSON里塞個字符串"10"，System.Text.Json默默幫你轉(zhuǎn)換。塞個null？屬性原樣保留默認值0。這種"貼心"讓無數(shù)生產(chǎn)事故在代碼審查階段完全隱身。

POCO不是解藥，是麻醉劑

行業(yè)慣例要求用POCO（plain old C# object，純C#對象）隔離序列化層與領(lǐng)域?qū)印Ｗ髡吒闪耸闏#，現(xiàn)在回頭看：這套做法像在漏水的船底鋪地毯。POCO確實解耦了，但把驗證責(zé)任推給了運行時——某個字段改名、某個嵌套結(jié)構(gòu)扁平化，編譯器零提示，線上直接炸。

Newtonsoft.Json和System.Text.Json的對比更有意思。前者是老江湖，配置項多到能寫本書；后者是微軟親兒子，性能快了三倍，但"默認寬容"的脾氣一點沒改。兩者共享同一個底層假設(shè)：開發(fā)者希望反序列化"Just Works"。

作者舉了個典型場景。假設(shè)API返回的address.number從字符串變成整數(shù)，POCO里的string Number會當(dāng)場拋異?！绻_了嚴(yán)格模式的話。沒開？那你會得到一個空字符串，下游邏輯繼續(xù)跑，數(shù)據(jù)污染像病毒一樣擴散。

函數(shù)式語言的"顯式解碼"是什么體驗

作者現(xiàn)在主力用Gleam，這門語言的JSON處理徹底拋棄了反射。沒有POCO，沒有自動映射，每個字段必須手寫解碼器（decoder）。代碼量確實多了，但錯誤處理從運行時前移到編譯期——JSON結(jié)構(gòu)對不上？類型檢查直接攔下。

這種范式轉(zhuǎn)換的核心差異：C#把反序列化當(dāng)成"數(shù)據(jù)搬家"，Gleam把它當(dāng)成"數(shù)據(jù)談判"。談判就得逐條確認：這個字段存在嗎？類型匹配嗎？轉(zhuǎn)換失敗怎么辦？作者形容這是"從自動駕駛切到手動檔"，但"至少你知道輪子在哪"。

顯式解碼的另一個副作用是性能。Gleam編譯器能內(nèi)聯(lián)解碼器，消除反射開銷。作者沒給具體數(shù)字，但提到一個觀察：同樣解析10MB的JSON日志，Gleam服務(wù)的內(nèi)存曲線比C#版本平緩得多，GC（垃圾回收）壓力不在一個量級。

折中方案：C#也能部分顯式

不想換語言？作者給了兩條退路。System.Text.Json的JsonConverter可以接管特定類型的反序列化邏輯，手寫驗證代碼?；蛘吒みM一點——放棄自動反序列化，先用JsonDocument解析成DOM（文檔對象模型），再逐字段提取并轉(zhuǎn)換。

兩條路都犧牲便利性換可靠性。作者自己的經(jīng)驗是：核心領(lǐng)域模型必須走顯式路線，邊緣DTO可以保留自動映射。"不是非黑即白，但得知道自己在妥協(xié)什么"。

文末作者留了句話：「這些想法是我職業(yè)生涯中慢慢形成的，對你未必適用，但值得實驗?！箾]有結(jié)論，沒有號召，只有一個老程序員對技術(shù)選型的誠實復(fù)盤。你的項目里，最近一次JSON解析異常是在測試階段還是生產(chǎn)環(huán)境發(fā)現(xiàn)的？