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

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

POCO不是解藥，是麻醉劑

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

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

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

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

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

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

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

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

不想換語言？作者給了兩條退路。System.Text.Json的JsonConverter可以接管特定類型的反序列化邏輯，手寫驗(yàn)證代碼。或者更激進(jìn)一點(diǎn)——放棄自動(dòng)反序列化，先用JsonDocument解析成DOM（文檔對(duì)象模型），再逐字段提取并轉(zhuǎn)換。

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

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