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