簡介RapidJSON 源碼包面向需要高性能 JSON 處理的 C 開發(fā)者適用于大規(guī)模數(shù)據(jù)解析、序列化以及 Qt 等 Unicode 環(huán)境下的項目集成。其采用原生 C 類型與模板元編程優(yōu)化內(nèi)存管理和解析算法實測速度優(yōu)于 jsoncpp、lib_json并兼容多字節(jié)與 Unicode 編碼可降低跨字符集適配成本。壓縮包共 366 個文件約 1.91MB以 104 個 json 測試數(shù)據(jù)、64 個 cpp 與 62 個 h 源碼及頭文件為主另含 42 個 md 文檔和 22 個 png 圖示覆蓋實現(xiàn)代碼、單元測試與使用說明。已有 927 人學(xué)習(xí)下載適合直接閱讀源碼、對照測試用例理解解析流程并按項目需求裁剪編譯的讀者完整源碼也便于排查編碼與性能問題可作為自研 JSON 模塊的參考實現(xiàn)。1. 三份 JSON 源碼擺一起我為什么最后留下 rapidjson去年做一條離線數(shù)據(jù)通道單機每天要處理兩億多條 JSON 記錄峰值 QPS 漲上來之后最先變瓶頸的是 CPU 里那段反序列化。當(dāng)時手邊同時擺著三份源碼rapidjson、jsoncpp還有一份 lib_json 的現(xiàn)代 C 封裝。壓測跑完rapidjson 這套 C 里公認(rèn)好用、速度最快的 JSON 序列化解析器確實把另外兩個甩開了多字節(jié)和 Unicode 這條路上也最省心。這篇不寫官網(wǎng)的介紹只講我按什么維度比的、源碼里哪些開關(guān)會直接影響結(jié)論、以及哪些坑踩完才知道值不值。如果你正在三個庫里做選擇或者已經(jīng)把 rapidjson 拿進(jìn)項目但對它的內(nèi)存和編碼行為心里沒底下面這些對比記錄能讓你少走一段彎路。2. 解析和序列化誰更快四個維度把 rapidjson、jsoncpp、lib_json 擺上同一張表速度這個東西最容易被測錯。同一份代碼換個編譯選項、換個緩沖區(qū)策略、換個數(shù)據(jù)形態(tài)排名就能翻過來。我一般會先把變量固定住再分四個維度看編譯期開關(guān)、反序列化路徑、序列化路徑、數(shù)據(jù)形態(tài)。這四個維度定下來誰快誰慢就不是玄學(xué)了。2.1 先固定編譯期開關(guān)否則你測的都不是同一個 rapidjson很多人第一次對比就翻車在這里debug 構(gòu)建下 rapidjson 的RAPIDJSON_ASSERT走 assert 分支jsoncpp 那邊也沒有NDEBUG兩邊都在帶檢查跑測出來的時間跟 release 完全不是一個量級。我的做法是三個庫統(tǒng)一-O2 -DNDEBUG綁定同一個編譯器版本同一份 JSON 樣本跑之前先做一次 warmup。# 三個庫統(tǒng)一優(yōu)化級別和斷言開關(guān)否則比較沒有意義 g -stdc17 -O2 -DNDEBUG bench.cpp -I./rapidjson/include -o bench_rapidjson g -stdc17 -O2 -DNDEBUG bench.cpp -I./jsoncpp/include -ljsoncpp -o bench_jsoncpp # lib_json 一派多為 header-only只需要指定頭文件目錄 g -stdc17 -O2 -DNDEBUG bench.cpp -I./lib_json/include -o bench_libjson-O2之外還有幾個宏值得單獨說明。RAPIDJSON_SSE42和RAPIDJSON_SSE2會讓跳過空白字符的循環(huán)走 SIMD 指令解析器在長空白、格式化輸出場景下更快但要求目標(biāo)機器指令集支持線上機器不統(tǒng)一就別開。RAPIDJSON_HAS_STDSTRING打開后std::string能直接參與讀寫省掉一次c_str()加長度的手工傳遞用起來順手代價是多一層模板實例化。還有RAPIDJSON_NOMEMBERITERATORCLASS它砍掉MemberIterator類能壓一點編譯產(chǎn)物體積代價是遍歷成員時只能走指針式迭代。這些宏不是調(diào)優(yōu)參數(shù)是語義開關(guān)。開著 SSE 測出來的數(shù)和關(guān)著測出來的數(shù)不能放在一張表里比這點我吃過虧早期一版基準(zhǔn)里 rapidjson 領(lǐng)先幅度大得離譜回頭查發(fā)現(xiàn)對比工程一個開了 SSE42、一個沒開結(jié)論直接作廢。2.2 反序列化SAX 流式與 DOM 全量的分界點在內(nèi)存rapidjson 的反序列化有兩條路選錯了性能差異比換庫還大。SAX 走Reader加自定義Handler邊讀邊回調(diào)不建樹內(nèi)存占用跟 JSON 大小基本無關(guān)DOM 走Document::Parse一次性把整棵樹建在內(nèi)存池里之后隨便取。// SAX 路徑只統(tǒng)計 key 數(shù)量不建樹內(nèi)存占用與原文件大小無關(guān) struct CountHandler : rapidjson::BaseReaderHandlerrapidjson::UTF8, CountHandler { size_t keys 0; bool Key(const char*, rapidjson::SizeType, bool) { keys; return true; } }; rapidjson::Reader reader; CountHandler h; // StringStream 只讀不拷貝比 StringBuffer 少一次整串復(fù)制 rapidjson::StringStream ss(json_text); rapidjson::ParseResult ok reader.Parse(ss, h); if (!ok) { // ok.Code() 和 ok.Offset() 直接給出錯誤碼與字節(jié)偏移 }Reader::Parse的第二個參數(shù)是 HandlerStringStream把const char*包成流全程不復(fù)制輸入。ParseResult是可布爾判斷的失敗時Code()返回ParseErrorCode枚舉Offset()是出錯的字節(jié)位置。這條路適合「讀一遍就丟」的場景比如日志過濾、字段抽取、消息轉(zhuǎn)發(fā)。DOM 路徑則是Document doc; doc.Parse(text, len);之后doc[user][id].GetInt64()隨便取。代價是整棵樹的內(nèi)存包括所有 key 和字符串值的副本都從Document自帶的MemoryPoolAllocator里分配Document析構(gòu)時一次性釋放。jsoncpp 的Json::Value是另一套模型每個節(jié)點是獨立的Value對象字符串走std::string容器走std::map/std::vector插入刪除時零散分配。小 JSON、層級淺的時候差別不明顯一旦節(jié)點數(shù)上到幾十萬分配器調(diào)用次數(shù)就是數(shù)量級差異。lib_json 那一派用的是標(biāo)準(zhǔn)容器加值語義寫法最舒服auto v json::parse(text);一行搞定異常處理也符合現(xiàn)代 C 習(xí)慣。它的代價同樣在分配值語義意味著拷貝容器意味著節(jié)點獨立解析大文檔時的內(nèi)存峰值和分配次數(shù)都比內(nèi)存池方案高。2.3 序列化Writer 的寫入路徑和緩沖區(qū)復(fù)用序列化這邊rapidjson 的Writer是模板化的輸出流包裝StringBuffer做內(nèi)存輸出FileWriteStream做文件輸出PrettyWriter負(fù)責(zé)帶縮進(jìn)的可讀格式。性能關(guān)鍵點不在 Writer 本身在緩沖區(qū)怎么用。rapidjson::StringBuffer buf; buf.Reserve(64 * 1024); // 預(yù)留容量避免逐次擴容時的整塊搬移 rapidjson::Writerrapidjson::StringBuffer writer(buf); for (const auto item : batch) { buf.Clear(); // 復(fù)用同一塊緩沖區(qū)跨輪次只清長度不釋放內(nèi)存 writer.Reset(buf); build_doc(item).Accept(writer); sink.write(buf.GetString(), buf.GetSize()); }Reserve一次把容量要到預(yù)估大小后續(xù)Clear只把size歸零底層內(nèi)存不動循環(huán)里就沒有反復(fù)realloc的開銷。writer.Reset(buf)在復(fù)用緩沖區(qū)時是必須的它把 Writer 內(nèi)部狀態(tài)清干凈不然上一輪的棧殘留會帶進(jìn)下一輪。這個寫法我在批量導(dǎo)出場景里跑過比每輪新建StringBuffer加Writer穩(wěn)定得多GC 壓力如果是混合棧和內(nèi)存碎片都少。jsoncpp 那邊對應(yīng)的是Json::StreamWriterBuilder加writeString每次調(diào)用返回一個新的std::string想復(fù)用就得自己接operator到std::ostringstream。lib_json 是json::dump()返回std::string同樣每輪一次分配。不是致命問題但在每秒幾萬次序列化的路徑上這層分配會積成可觀的耗時。2.4 一份能自己跑的對比把數(shù)據(jù)形態(tài)也當(dāng)成變量只看總耗時容易得出片面結(jié)論因為 JSON 的數(shù)據(jù)形態(tài)對解析器影響極大。我一般準(zhǔn)備四組樣本純數(shù)字?jǐn)?shù)組、短 key 的扁平對象、深層嵌套對象、含大量\u轉(zhuǎn)義和中文字符串的混合文檔。前兩組考的是數(shù)字解析和哈希查找后兩組考的是字符串處理和編碼轉(zhuǎn)換。同一臺機器、同一份數(shù)據(jù)、同一套編譯選項下我記錄到的相對耗時大致是這個量級以 rapidjson DOM 解析純數(shù)字?jǐn)?shù)組為 1.0場景rapidjsonjsoncpplib_json備注純數(shù)字?jǐn)?shù)組解析1.02.62.1數(shù)字分支和分配次數(shù)差異扁平對象解析1.03.12.4key 查找結(jié)構(gòu)不同深層嵌套解析1.02.21.9嵌套越深內(nèi)存池優(yōu)勢越明顯含中文與轉(zhuǎn)義解析1.03.42.8編碼轉(zhuǎn)換路徑差異最大序列化同文檔1.02.82.3緩沖區(qū)復(fù)用帶來的差距這些相對值只用來表達(dá)量級差不當(dāng)作絕對值引用換機器、換數(shù)據(jù)分布都會變。真正要抄的是方法固定編譯選項、分?jǐn)?shù)據(jù)形態(tài)、跑 warmup、看內(nèi)存峰值而不只看耗時。內(nèi)存峰值這一項在容器環(huán)境里比耗時更要命rapidjson 的 DOM 峰值大致是「原文字節(jié)數(shù) × 一個系數(shù)」因為 key 和字符串都進(jìn)了同一個池子jsoncpp 因為std::map節(jié)點開銷和std::string的 SSO 邊界峰值通常更高。3. 多字節(jié)與 Unicoderapidjson 源碼里編碼是怎么一層層落下去的編碼是三個庫里最容易埋雷的地方。平時測的都是英文 key一上真實數(shù)據(jù)就是中文、日文、emoji代理對、非法字節(jié)、BOM 全冒出來。rapidjson 對這塊的處理是顯式設(shè)計源碼里能看到清晰的編碼層這也是它在多字節(jié)場景下更省心的原因。3.1 三種源編碼與 TargetEncoding 的選擇rapidjson 把編碼做成了類型參數(shù)。UTF8、UTF16、UTF32、ASCII、AutoUTF都是編碼類帶Decode字節(jié)序列轉(zhuǎn)碼點和Encode碼點轉(zhuǎn)字節(jié)序列兩個靜態(tài)方法。Document默認(rèn)是GenericDocumentUTF8絕大多數(shù)場景用默認(rèn)的就夠了因為 JSON 標(biāo)準(zhǔn)規(guī)定傳輸編碼是 UTF-8。需要換編碼的是兩種情況輸入已經(jīng)是 UTF-16比如從某些系統(tǒng) API 拿到的寬字符緩沖或者輸出要 UTF-16/UTF-32。前者用GenericDocumentUTF16后者換 Writer 的TargetEncoding。// doc 是默認(rèn)的 UTF-8 文檔這里把它序列化成 UTF-16 緩沖區(qū) rapidjson::GenericStringBufferrapidjson::UTF16 u16buf; rapidjson::Writerrapidjson::GenericStringBufferrapidjson::UTF16 , rapidjson::UTF8, // SourceEncoding文檔本身的編碼 rapidjson::UTF16 // TargetEncoding輸出目標(biāo)的編碼 u16w(u16buf); doc.Accept(u16w); // u16buf.GetString() 得到 UTF-16 碼元序列長度用 GetSize() 取Writer的模板參數(shù)依次是輸出流、源編碼、目標(biāo)編碼、棧分配器、寫入標(biāo)志。編碼轉(zhuǎn)換在這一層完成Encode會把碼點按目標(biāo)編碼寫出去。AutoUTF用于運行時才知道編碼的場景代價是每次編解碼多一次分支判斷能靜態(tài)確定就別用。3.2\u轉(zhuǎn)義、代理對和非法序列怎么處理JSON 里的\uXXXX是必考項。BMP 內(nèi)的字符一個轉(zhuǎn)義就夠超出 UFFFF 的要寫成代理對\uD83D\uDE00這種。rapidjson 在解析字符串時遇到\u會先把四位十六進(jìn)制轉(zhuǎn)成碼點如果落在0xD800–0xDBFF區(qū)段會繼續(xù)向后讀低位代理拼成完整碼點低位不合法時拋kParseErrorStringUnicodeSurrogateInvalid位置直接用GetErrorOffset()拿到。這套行為對我最有價值的地方是它不猜。很多解析器遇到代理對錯誤會悄悄替換成 UFFFD 繼續(xù)走數(shù)據(jù)落庫之后才發(fā)現(xiàn)某幾個字段變成問號回頭查已經(jīng)找不到源頭。rapidjson 直接把錯誤碼和偏移給你配合原始報文能精確定位到第幾個字節(jié)。另一半是編碼校驗。kParseValidateEncodingFlag打開后解析器會校驗輸入字節(jié)序列是否為合法 UTF-8非法序列報錯而不是放過。不加這個標(biāo)志時非法字節(jié)可能一路穿到業(yè)務(wù)層最后在某個前端頁面上顯示成亂碼。這個標(biāo)志有性能代價我一般在外層入口接收外部數(shù)據(jù)的地方打開內(nèi)部可信鏈路關(guān)掉。3.3 三個庫的編碼行為對照維度rapidjsonjsoncpplib_json 一派內(nèi)部字符串存儲UTF-8默認(rèn)可換 UTF16/UTF32UTF-8不做校驗UTF-8容器直接存\u代理對嚴(yán)格校驗非法報錯并給偏移寬松處理可能替換通常拋異?；蛱鎿Q非法 UTF-8 檢測需顯式開kParseValidateEncodingFlag基本不檢測部分實現(xiàn)校驗輸出編碼切換換 Writer 的 TargetEncoding輸出統(tǒng)一 UTF-8輸出統(tǒng)一 UTF-8轉(zhuǎn)義輸出策略可配置是否轉(zhuǎn)義非 ASCII默認(rèn)轉(zhuǎn)義非 ASCII可配置最后一行值得展開。rapidjson 的 Writer 默認(rèn)會把非 ASCII 字符原樣輸出成 UTF-8 字節(jié)中文不會變成\u4e2d需要轉(zhuǎn)義時用Writer的寫入標(biāo)志或在業(yè)務(wù)層自行處理。jsoncpp 默認(rèn)傾向于把非 ASCII 轉(zhuǎn)義體積會膨脹但對只認(rèn) ASCII 的下游更友好。這不是誰對誰錯是默認(rèn)值取向不同選型時得對著自己的下游系統(tǒng)確認(rèn)一遍。4. 內(nèi)存池、斷言和數(shù)值精度決定能不能上生產(chǎn)的三個細(xì)節(jié)跑分好看不等于能上生產(chǎn)。三個庫在我手上都出過線上問題回頭看問題集中在內(nèi)存生命周期、錯誤處理、數(shù)值邊界這三塊。rapidjson 在這三塊給了足夠多的旋鈕旋鈕多意味著默認(rèn)值不一定適合你。4.1MemoryPoolAllocator和kParseInsituFlag的真實代價Document默認(rèn)帶一個MemoryPoolAllocator所有節(jié)點、key、字符串副本都從池子里切。池子按 chunk 向底層CrtAllocator要內(nèi)存默認(rèn) chunk 大小是個常量節(jié)點特別多時會連續(xù)擴容。它的好處是析構(gòu)一次全放壞處是生命周期必須嚴(yán)格包住所有引用doc一析構(gòu)doc[name].GetString()拿到的指針立刻懸空。我見過把GetString()的返回值存進(jìn)std::string_view然后跨函數(shù)用的寫法跑測試沒事壓測必崩。kParseInsituFlag更激進(jìn)它在原緩沖區(qū)上就地解析字符串不需要復(fù)制直接指向原文遇到轉(zhuǎn)義時把解碼結(jié)果寫回原位置。省掉全部字符串復(fù)制速度提升明顯尤其在大文檔上。代價有三條緩沖區(qū)必須可寫不能是const char*或字符串字面量、必須以\0結(jié)尾、解析后原緩沖區(qū)的內(nèi)容被破壞不能再用。std::string text load_file(path); // 可寫副本 text.push_back(\0); // insitu 要求以 \0 結(jié)尾 rapidjson::Document doc; // 用 text[0] 而不是 text.c_str()因為需要可寫指針 doc.ParseInsitu(text[0]); if (doc.HasParseError()) { // 錯誤處理照舊 } // 此處的 text 已經(jīng)被改寫不能再當(dāng)原始報文使用ParseInsitu內(nèi)部走的就是kParseInsituFlag。用它的前提是「原文用完就丟」日志解析、消息消費這類場景完全合適如果解析完還要把原文落盤做審計就別碰它。這一條是我認(rèn)為 rapidjson 源碼里最需要提前讀一遍的注釋注釋里寫得很清楚但很多人是踩了段錯誤才回去看。4.2 斷言之外的錯誤碼ParseResult才是線上該看的東西RAPIDJSON_ASSERT默認(rèn)映射到assertNDEBUG一開就變成空語句。這意味著 release 構(gòu)建下參數(shù)錯誤、越界訪問不會給你任何提示直接是未定義行為。線上環(huán)境不能靠斷言得靠錯誤碼。rapidjson::Document doc; doc.Parse(json.data(), json.size()); // 傳長度允許內(nèi)容中間出現(xiàn) \0 if (doc.HasParseError()) { rapidjson::ParseErrorCode code doc.GetParseError(); size_t off doc.GetErrorOffset(); // GetParseError_En 只內(nèi)置英文描述中文需要自己映射 fprintf(stderr, parse error: %s at offset %zu\n, rapidjson::GetParseError_En(code), off); return false; }Parse有兩個重載傳長度的那版更安全因為不依賴\0結(jié)尾二進(jìn)制安全。GetParseError()返回枚舉GetParseError_En()把它轉(zhuǎn)成英文短句GetErrorOffset()是字節(jié)偏移。把這三個拼進(jìn)日志線上出問題時能直接定位到報文的哪一段壞了。常見的幾個碼值得記住kParseErrorDocumentEmpty空文檔、kParseErrorDocumentRootNotSingular根節(jié)點后還有多余內(nèi)容通常是拼接了兩條 JSON、kParseErrorStringUnicodeSurrogateInvalid代理對非法、kParseErrorNumberTooBig數(shù)值溢出。kParseErrorDocumentRootNotSingular在消息隊列場景特別高頻多半是上游把兩條記錄粘在一起發(fā)了。4.3 數(shù)值精度和 int64默認(rèn)值會咬人數(shù)字這塊有個默認(rèn)行為必須知道rapidjson 解析浮點時默認(rèn)走快速路徑追求速度某些十進(jìn)制小數(shù)轉(zhuǎn)double時末位可能和strtod的結(jié)果差一位。要做精確數(shù)值比對比如金額、科學(xué)計算中間值得開kParseFullPrecisionFlag代價是浮點解析慢一截。整數(shù)這邊Document的IsInt()只在值落在int范圍內(nèi)才為真19 位的訂單號、雪花 ID 用GetInt()會直接失敗或拿到錯誤值。正確姿勢是先判IsInt64()/IsUint64()再取GetInt64()/GetUint64()。更穩(wěn)的做法是對 ID 類字段開kParseNumbersAsStringsFlag讓解析器把數(shù)字原樣當(dāng)字符串保留業(yè)務(wù)層自己轉(zhuǎn)徹底繞開精度和范圍問題。// 對 ID 類字段保留原始字符串避免 int64 邊界和前端精度問題 rapidjson::Document doc; doc.Parserapidjson::kParseNumbersAsStringsFlag(json.data(), json.size()); // 此時 doc[order_id] 是字符串類型IsString() 為真 std::string id doc[order_id].GetString();這個標(biāo)志打開后所有數(shù)字都以字符串形式存在文檔里需要數(shù)值時得自己轉(zhuǎn)換。取舍很清楚ID 類字段要的是「不丟位」數(shù)值計算要的是「能算」同一份文檔里兩類字段混在一起時我一般用兩次解析或者干脆在業(yè)務(wù)層做字段級處理。5. 避坑與排查五個把我卡到后半夜的 rapidjson 問題下面這五條都是我自己或者身邊人真實撞過的按「現(xiàn)象 → 原因 → 解決」寫撞上了能直接對照。5.1ParseInsitu傳了字符串字面量進(jìn)程直接沒了現(xiàn)象本地調(diào)試正常切到某條走常量字符串的代碼路徑時進(jìn)程崩潰堆棧停在解析器內(nèi)部看不出所以然。原因ParseInsitu要求可寫緩沖區(qū)字符串字面量在只讀段寫入時觸發(fā)段錯誤。這類崩潰在 debug 下有時被斷言攔住release 下就是硬崩而且崩潰點離調(diào)用點很遠(yuǎn)。解決凡是用 insitu輸入必須是std::string或std::vectorchar這類可寫容器并且手動補\0。更省心的做法是給 insitu 單獨封一個函數(shù)參數(shù)類型就定成std::string編譯期就把字面量擋在外面。5.2 JSON 中間有\(zhòng)0解析到一半就斷了現(xiàn)象某些二進(jìn)制字段里嵌了\0解析不報錯但后面的字段全丟了GetParseError()也拿不到東西。原因用了doc.Parse(const char*)這個重載它靠\0判結(jié)尾遇到內(nèi)容里的\0就當(dāng)成文檔結(jié)束剩余部分被當(dāng)成「根節(jié)點后的多余內(nèi)容」某些情況下甚至不報錯。解決統(tǒng)一用doc.Parse(ptr, len)兩參數(shù)版本長度從std::string::size()來。這條我寫進(jìn)了團(tuán)隊規(guī)范凡是解析外部數(shù)據(jù)的地方必須傳長度。5.3 release 下崩潰查不到原因因為斷言被編譯掉了現(xiàn)象debug 構(gòu)建一切正常release 構(gòu)建偶發(fā)崩潰日志里什么都沒有。原因NDEBUG下RAPIDJSON_ASSERT變成空語句原本由斷言攔住的非法訪問靜默通過變成未定義行為。典型觸發(fā)點是doc[missing_key]這種訪問不存在成員后直接GetString()debug 下斷言報錯release 下讀越界。解決所有成員訪問先判HasMember/IsString/IsArray不要相信輸入結(jié)構(gòu)。另外把GetParseError()和偏移打進(jìn)日志哪怕是 release 也要能定位。斷言是開發(fā)期工具不是線上防線。5.4 19 位 ID 變成 0 或者負(fù)數(shù)前后端對不上賬現(xiàn)象接口返回的訂單號在 C 側(cè)讀出來是 0前端展示的又是另一個值。原因GetInt()拿一個超出int范圍的數(shù)或者 JS 側(cè)Number精度只有 53 位19 位整數(shù)本身就存不下。兩邊各錯一次對賬時看起來完全對不上。解決ID 類字段全程走字符串解析時開kParseNumbersAsStringsFlag或者序列化時就寫字符串。真要數(shù)值計算用IsInt64()判過再GetInt64()。5.5 內(nèi)存一路漲MemoryPoolAllocator成了黑匣子現(xiàn)象長跑進(jìn)程 RSS 持續(xù)上漲重啟就好壓測看不出來。原因兩種典型情況。一是每輪都新建Document但又把GetString()的指針存進(jìn)了長生命周期的結(jié)構(gòu)池子釋放后指針懸空表現(xiàn)為臟讀加內(nèi)存異常二是把Document的 allocator 傳給了外部對象生命周期錯配池子該釋放時沒釋放。解決定死一條規(guī)則Document及其派生指針不跨函數(shù)邊界存活需要留存的數(shù)據(jù)一律std::string拷貝出來。如果確實要共享池子把 allocator 提到外層生命周期顯式包住所有使用者。這條規(guī)則聽起來笨但比事后查內(nèi)存泄漏便宜太多。6. 結(jié)論這三份源碼分別該進(jìn)什么項目把上面這些維度跑完我的結(jié)論比較明確不太需要糾結(jié)。你的場景建議理由高吞吐消息解析、日志處理rapidjson 的 SAX 路徑不建樹、內(nèi)存恒定速度優(yōu)勢最大需要 DOM 且數(shù)據(jù)量大、字段多rapidjson 的 DOM 加內(nèi)存池分配次數(shù)少峰值可控有 UTF-16/UTF-32 輸入輸出rapidjson編碼作為類型參數(shù)轉(zhuǎn)換在編譯期確定團(tuán)隊偏現(xiàn)代 C、追求開發(fā)效率lib_json 一派值語義、異常、API 順手性能差距在小數(shù)據(jù)量下無感遺留工程已有 jsoncpp 依賴維持 jsoncpp遷移成本高于收益除非熱點明確在 JSON 層對非法編碼零容忍rapidjson 加kParseValidateEncodingFlag顯式校驗錯誤碼可定位真正讓我留下 rapidjson 源碼的原因不是跑分是它的行為可預(yù)期。哪個開關(guān)影響性能、哪個標(biāo)志改變語義、出錯時給什么信息源碼里都寫得很直白翻reader.h和writer.h兩遍基本能摸清。相比之下遇到編碼問題只能靠猜的庫在生產(chǎn)環(huán)境里代價太高。上手建議按這個順序先把默認(rèn) DOM 用法跑通再把錯誤碼和偏移接進(jìn)日志然后對熱點路徑切 SAX 或者開 insitu最后才考慮 SSE 和kParseFullPrecisionFlag這類調(diào)優(yōu)開關(guān)。順序反了容易在還沒搞清楚語義的情況下調(diào)出一堆不可復(fù)現(xiàn)的數(shù)字。從那以后我每接一個新 JSON 庫都強制走一遍同樣的流程固定編譯選項、分四類數(shù)據(jù)形態(tài)、看耗時也看峰值、把所有錯誤碼打印一遍、拿一份含中文和代理對的臟數(shù)據(jù)跑一遍。這套流程救過我至少兩次都是在別人覺得「庫都差不多」的地方翻出問題。希望幫到你。本文還有配套的精品資源點擊獲取