簡介cpr-1.3.0 預(yù)編譯庫面向使用 C 發(fā)起 HTTP 請求的開發(fā)者適合在 VS 項(xiàng)目中快速接入、又不想自行編譯 cpr 與 libcurl 的初、中級人員。壓縮包共 27 個(gè)文件含 21 個(gè)頭文件、4 個(gè) lib 靜態(tài)庫和 2 個(gè) dll 動(dòng)態(tài)庫Debug/Release 均提供 cpr.lib、libcurl.dll 等整體約 738KB便于隨工程歸檔引用。資源由 weststarqp 于 2019 年 2 月基于 VS2015 編譯已有 691 人學(xué)習(xí)。解壓后可按配置將頭文件、庫文件與動(dòng)態(tài)庫加入工程減少搭建依賴環(huán)境的時(shí)間并借助頭文件了解 session、response、auth、cookies 等接口為請求封裝和調(diào)試提供基礎(chǔ)。1. 從一次庫在頭文件不在的編譯失敗說起上周接手一個(gè)內(nèi)部工具的構(gòu)建CMakeLists 里一行find_package(cpr REQUIRED)我以為是十分鐘的事結(jié)果make直接甩出一堆fatal error: cpr/generated/cpr_generated_includes.h: No such file or directory。庫文件明明裝了頭文件目錄也加進(jìn)-I了偏偏缺一個(gè)名字很長的中間頭文件。這就是 cpr 1.3.0 最經(jīng)典的一關(guān)。cpr 全稱 C Requests是把 libcurl 那套 C 接口包成cpr::Get/cpr::Response風(fēng)格的 C11 庫寫 HTTP 客戶端時(shí)不用再和curl_easy_setopt的變參列表較勁。它常見于數(shù)據(jù)采集、內(nèi)部服務(wù)探活、CI 里的小工具這類場景。裝不順的后果很直接編譯期缺頭鏈接期缺符號(hào)運(yùn)行期 SSL 握手失敗一路踩下來比手寫 libcurl 還費(fèi)時(shí)間。這篇記錄適合正在找 cpr-1.3.0 怎么安裝、怎么配置、環(huán)境怎么搭的人。2. 環(huán)境盤點(diǎn)cpr 1.3.0 編起來到底要哪幾樣?xùn)|西動(dòng)手之前先把依賴列清楚比編到一半再回頭補(bǔ)要省事得多。cpr 1.3.0 本身不復(fù)雜它就是一層薄封裝真正的重活在 libcurl 和 OpenSSL 上。麻煩的地方在于它的 CMake 腳本默認(rèn)行為偏自給自足會(huì)嘗試自己去弄 curl 源碼這在有外網(wǎng)的開發(fā)機(jī)上無感在隔離環(huán)境里就是災(zāi)難。所以這一章的重點(diǎn)不是羅列依賴而是把每個(gè)依賴的來源定下來編譯器從系統(tǒng)來curl 從系統(tǒng)來SSL 從系統(tǒng)來三樣都鎖死構(gòu)建過程才是可復(fù)現(xiàn)的。2.1 編譯器與 C 標(biāo)準(zhǔn)C11 是底線不是可選項(xiàng)cpr 1.3.0 的公開頭文件里用了std::function、std::unordered_map、右值引用和大量 lambda編譯選項(xiàng)里必須打開 C11。GCC 建議 7 以上Clang 建議 6 以上MSVC 走 2017 以后的版本比較穩(wěn)。我一般不去賭默認(rèn)標(biāo)準(zhǔn)而是在工程頂層直接寫死避免某個(gè)下游工程把-std覆蓋掉之后報(bào)出一堆看不懂的模板推導(dǎo)錯(cuò)誤。# 頂層 CMakeLists.txt在 project() 之后立刻設(shè)置 set(CMAKE_CXX_STANDARD 11) set(CMAKE_CXX_STANDARD_REQUIRED ON) # 找不到 C11 編譯器就直接失敗而不是悄悄降級 set(CMAKE_CXX_EXTENSIONS OFF) # 關(guān)掉 gnu11保持可移植這三行的邏輯是第一行聲明目標(biāo)標(biāo)準(zhǔn)第二行把必須有變成硬約束第三行避免編譯期混入 GNU 擴(kuò)展導(dǎo)致?lián)Q編譯器就編不過。很多在我機(jī)器上能編的事故源頭就是CMAKE_CXX_EXTENSIONS默認(rèn)開著代碼里不小心用了typeof之類的東西換到 Clang 上直接崩。如果你的工程已經(jīng)是 C14 或 C17不用降級cpr 1.3.0 在更高標(biāo)準(zhǔn)下也能編只是別把-stdc98這種老配置帶進(jìn)來。2.2 libcurl 用系統(tǒng)的還是自帶的一個(gè)決定影響后面所有鏈接錯(cuò)誤cpr 的 CMake 里有一個(gè)開關(guān)叫CPR_FORCE_USE_SYSTEM_CURL默認(rèn)是關(guān)閉的。關(guān)閉狀態(tài)下構(gòu)建腳本會(huì)嘗試把 curl 源碼弄到本地再一起編。這個(gè)設(shè)計(jì)對想零依賴的人友好但在實(shí)際部署里問題不少構(gòu)建過程會(huì)依賴外部源碼獲取網(wǎng)絡(luò)受限時(shí)直接卡住就算拿到了源碼編出來的 curl 和系統(tǒng)里其他程序用的 curl 也是兩份后面做動(dòng)態(tài)鏈接時(shí)符號(hào)容易打架。我的做法是一律強(qiáng)制用系統(tǒng) curl前提是先確認(rèn)開發(fā)包裝好了# Debian / Ubuntu 系裝 curl 的開發(fā)頭文件和靜態(tài)庫 sudo apt-get install -y libcurl4-openssl-dev # RHEL / CentOS 系 sudo yum install -y libcurl-devel # 確認(rèn)系統(tǒng)里的 curl 版本低于 7.50 建議先升級 curl-config --version curl-config --libs # 看鏈接參數(shù)里是否帶 -lssl -lcryptolibcurl4-openssl-dev這個(gè)名字不是隨便挑的它決定了 curl 背后用的是 OpenSSL 而不是別的 TLS 實(shí)現(xiàn)。cpr 的 SSL 相關(guān)代碼路徑和 curl 的 TLS 后端是綁定的混用會(huì)出現(xiàn)編譯通過但運(yùn)行期證書校驗(yàn)行為異常這種很難查的問題。curl-config --libs的輸出要重點(diǎn)看如果里面沒有-lssl -lcrypto說明裝的是不帶 SSL 的版本后面CPR_ENABLE_SSLON會(huì)直接失敗。裝完開發(fā)包后再跑一次curl-config --version把版本號(hào)記下來后面排查時(shí)有用。2.3 OpenSSL 與 zlibSSL 開關(guān)背后的兩個(gè)真實(shí)依賴cpr 1.3.0 的CPR_ENABLE_SSL默認(rèn)打開打開之后就會(huì)去找 OpenSSL 的頭文件和庫。1.1.1 系列是目前兼容性最好的選擇如果系統(tǒng)里是 3.x多數(shù)情況下也能編但要留意 cpr 這層封裝里對舊宏的引用個(gè)別發(fā)行版會(huì)報(bào)OPENSSL_VERSION_NUMBER相關(guān)的棄用警告警告本身不影響產(chǎn)物但會(huì)淹沒真正的錯(cuò)誤信息。zlib 的情況稍微特殊一點(diǎn)cpr 本身不直接用 zlib但 curl 在開啟內(nèi)容壓縮支持時(shí)會(huì)依賴它。如果你的請求需要帶Accept-Encoding: gzip那 curl 編的時(shí)候就必須帶 zlib否則服務(wù)端返回壓縮體時(shí)你拿到的是亂碼。檢查辦法很直接# 看 curl 的編譯特性里有沒有 zlib 和 SSL curl -V # 輸出里的 Features 一行應(yīng)包含 libz、SSL、HTTPS-proxy 等關(guān)鍵字這一步屬于裝之前花十秒裝之后省兩小時(shí)的檢查。很多環(huán)境里 curl 是精簡版編譯的特性列表里沒有 libz等到業(yè)務(wù)代碼里手動(dòng)解壓失敗才發(fā)現(xiàn)回頭重裝 curl 還得連帶重編 cpr代價(jià)不小。2.4 一套我常用的版本組合下面這張表是我這幾年在不同機(jī)器上落地過的組合不是官方要求只是這個(gè)范圍內(nèi)我沒翻過車的經(jīng)驗(yàn)區(qū)間?？绱蟀姹緯r(shí)差異會(huì)放大比如把 curl 從 7.x 換到 8.x鏈接參數(shù)和部分宏定義都有變化需要重新驗(yàn)證一遍。組件推薦區(qū)間說明CMake3.10 及以上低版本對target_include_directories的 install 導(dǎo)出支持不全GCC7 及以上低于 7 時(shí) C11 的std::string_view替代實(shí)現(xiàn)容易出問題Clang6 及以上與 libstdc 搭配時(shí)注意版本匹配libcurl7.58 及以上7.58 前后 SSL 相關(guān)宏有調(diào)整1.3.0 在舊版上偶發(fā)編譯錯(cuò)誤OpenSSL1.1.1 系列兼容性最好3.x 可用但會(huì)有棄用警告zlib1.2.8 及以上只影響壓縮傳輸不影響基礎(chǔ)請求這張表的意義在于縮小排查范圍。當(dāng)你遇到一個(gè)詭異的編譯錯(cuò)誤時(shí)先對照表格確認(rèn)自己不在邊緣組合上再去翻代碼效率會(huì)高很多。3. 編譯安裝把 cpr 1.3.0 裝進(jìn)一個(gè)干凈前綴到這一步依賴都齊了可以開始編。我強(qiáng)烈建議裝到獨(dú)立前綴而不是/usr/local原因很現(xiàn)實(shí)cpr 1.3.0 是幾年前的版本你手上可能還有別的工程依賴更高版本的 cpr全都塞進(jìn)/usr/local之后find_package找到哪個(gè)全看運(yùn)氣。獨(dú)立前綴加上CMAKE_PREFIX_PATH能把這套依賴隔離得干干凈凈卸載的時(shí)候一個(gè)rm -rf就完事不留殘?jiān)?.1 源碼落地與 out-of-source 構(gòu)建目錄先建兩個(gè)目錄一個(gè)放源碼一個(gè)放構(gòu)建產(chǎn)物嚴(yán)格分開。in-source 構(gòu)建在 cpr 這種帶代碼生成的工程里尤其危險(xiǎn)中間文件會(huì)污染源碼樹下次換配置時(shí) CMakeCache 里全是臟數(shù)據(jù)。# 目錄規(guī)劃源碼和產(chǎn)物分開安裝前綴獨(dú)立 mkdir -p ~/work/cpr-1.3.0-src mkdir -p ~/work/build-cpr mkdir -p /opt/cpr-1.3.0 # 假設(shè)源碼包已經(jīng)解壓到 ~/work/cpr-1.3.0-src cd ~/work/cpr-1.3.0-src ls CMakeLists.txt include/ # 確認(rèn)目錄結(jié)構(gòu)對得上再往下走ls這一步別省。有些壓縮包解開后多套一層目錄直接cmake -S .會(huì)報(bào)找不到 CMakeLists.txt新手容易在這里懷疑人生。確認(rèn)CMakeLists.txt和include/在同一層就是正確的源碼根目錄。安裝前綴/opt/cpr-1.3.0里的版本號(hào)也別省將來并存多個(gè)版本時(shí)這個(gè)命名能救你一次。3.2 CMake 關(guān)鍵選項(xiàng)逐個(gè)拆配置階段是整個(gè)安裝過程里最值得花時(shí)間的地方。下面這條命令是我在大多數(shù)環(huán)境里用的版本參數(shù)看著多但每一項(xiàng)都對應(yīng)一個(gè)具體的失敗場景。cmake -S ~/work/cpr-1.3.0-src \ -B ~/work/build-cpr \ -DCMAKE_BUILD_TYPERelease \ -DCMAKE_INSTALL_PREFIX/opt/cpr-1.3.0 \ -DCPR_BUILD_TESTSOFF \ -DCPR_BUILD_SERVEROFF \ -DCPR_ENABLE_SSLON \ -DCPR_FORCE_USE_SYSTEM_CURLON \ -DBUILD_SHARED_LIBSON \ -DCMAKE_POSITION_INDEPENDENT_CODEON逐項(xiàng)說明-S和-B是現(xiàn)代 CMake 的寫法分別指源碼目錄和構(gòu)建目錄等價(jià)于進(jìn)目錄再跑cmake ..但更不容易出錯(cuò)。CMAKE_BUILD_TYPERelease打開優(yōu)化并去掉調(diào)試符號(hào)。cpr 1.3.0 在 Debug 下編出來的庫體積會(huì)大不少作為依賴庫沒必要。CMAKE_INSTALL_PREFIX決定make install往哪寫這里就是前面建好的獨(dú)立前綴。CPR_BUILD_TESTSOFF很關(guān)鍵。打開后它會(huì)去找測試框架在你沒有預(yù)裝的環(huán)境里會(huì)直接失敗而且測試代碼本身對產(chǎn)物沒有任何貢獻(xiàn)。CPR_BUILD_SERVEROFF關(guān)掉配套的測試服務(wù)端同理。CPR_ENABLE_SSLON顯式打開別依賴默認(rèn)值尤其在別人寫好的構(gòu)建腳本里。CPR_FORCE_USE_SYSTEM_CURLON是前面 2.2 節(jié)說過的那個(gè)決定必須顯式指定。BUILD_SHARED_LIBSON出動(dòng)態(tài)庫。如果你的部署環(huán)境不方便帶.so改成OFF出靜態(tài)庫這個(gè)取舍在第 4 章細(xì)說。CMAKE_POSITION_INDEPENDENT_CODEON保證生成的庫能被鏈接進(jìn)動(dòng)態(tài)庫即使當(dāng)前選的是靜態(tài)庫也建議開著。配置跑完后重點(diǎn)看輸出的末尾幾行會(huì)打印出檢測到的 curl 版本、SSL 后端、是否啟用 zlib。這三行信息比任何文檔都真實(shí)因?yàn)樗菑漠?dāng)前這臺(tái)機(jī)器上探測出來的。3.3 編譯、安裝以及 generated 頭文件這一關(guān)cmake --build ~/work/build-cpr -j$(nproc) cmake --install ~/work/build-cpr-j后面跟并行度用nproc拿到核數(shù)就行。cpr 本身編譯很快瓶頸通常在它要不要額外編 curl一旦看到編譯過程里出現(xiàn)了大量 curl 的源文件說明 3.2 節(jié)那個(gè)開關(guān)沒生效回去檢查參數(shù)拼寫。安裝完之后必須做一次落地檢查這是整個(gè)流程里最容易被跳過、也最容易出問題的一步# 檢查關(guān)鍵頭文件和庫是否真的落到了前綴目錄 find /opt/cpr-1.3.0 -name *.h | head -20 find /opt/cpr-1.3.0 -name libcpr* ls /opt/cpr-1.3.0/lib/cmake/cpr/ 2/dev/null || echo 缺 CMake 配置文件三條命令分別查頭文件、庫文件、CMake 包配置。重點(diǎn)看頭文件列表里有沒有一個(gè)路徑里帶generated字樣的文件——cpr 1.3.0 在構(gòu)建時(shí)會(huì)生成一份與 curl 頭文件版本相關(guān)的中間頭文件而老版本的安裝規(guī)則在某些平臺(tái)上不會(huì)把它一起裝進(jìn)去于是出現(xiàn)第 1 章開頭那個(gè)報(bào)錯(cuò)。如果確實(shí)缺了從構(gòu)建目錄里找出來手動(dòng)補(bǔ)進(jìn)去# 在構(gòu)建目錄里定位生成的中間頭文件 find ~/work/build-cpr -name cpr_generated_includes.h # 找到后按原相對路徑補(bǔ)到安裝前綴 mkdir -p /opt/cpr-1.3.0/include/cpr/generated cp ~/work/build-cpr/include/cpr/generated/cpr_generated_includes.h \ /opt/cpr-1.3.0/include/cpr/generated/補(bǔ)完之后再find一次確認(rèn)。這一步屬于典型的官方安裝規(guī)則沒覆蓋到的坑不補(bǔ)的話下游工程#include cpr/cpr.h必然失敗而且報(bào)錯(cuò)指向的是一個(gè)你沒寫過的文件名第一眼很難聯(lián)想到是安裝不完整。CMake 里還有個(gè)CPR_GENERATED_SOURCES_DIRECTORY變量可以用來指定生成物的輸出位置不同小版本行為不完全一致我最后都會(huì)用上面這條手動(dòng)校驗(yàn)兜底不賭它的默認(rèn)行為。另外如果目標(biāo)是直接拿現(xiàn)成的庫文件用那么落地檢查同樣適用頭文件樹里必須有cpr/cpr.h、cpr/generated/下那個(gè)生成文件、lib/下的庫以及l(fā)ib/cmake/cpr/下的配置文件四樣少一樣都不算完整。少 CMake 配置文件的后果是find_package直接失敗很多人在這一步誤以為是版本不匹配其實(shí)只是安裝不完整。3.4 find_package 接入與 pkg-config 備選安裝到位之后在下游工程里就該能直接找到了。標(biāo)準(zhǔn)寫法# 下游工程的 CMakeLists.txt find_package(cpr REQUIRED) add_executable(probe main.cpp) target_link_libraries(probe PRIVATE cpr::cpr)find_package會(huì)去CMAKE_PREFIX_PATH里找cprConfig.cmake所以如果裝在/opt下配置時(shí)要帶上路徑cmake -S . -B build -DCMAKE_PREFIX_PATH/opt/cpr-1.3.0如果find_package報(bào)找不到先別懷疑版本按順序查三件事配置文件是否在lib/cmake/cpr/下、CMAKE_PREFIX_PATH是否傳進(jìn)去了、前置的 curl 是否也能被找到。第三條經(jīng)常被忽略——cpr 的配置文件里會(huì)find_dependency(CURL)如果你把 cpr 裝到了前綴里但 curl 是系統(tǒng)包通常沒問題反過來把 curl 也裝在獨(dú)立前綴里卻忘了把那個(gè)前綴加進(jìn)搜索路徑就會(huì)在find_package(cpr)這一行報(bào)出莫名其妙的依賴錯(cuò)誤。target_link_libraries里的cpr::cpr是導(dǎo)出目標(biāo)名。個(gè)別打包方式下目標(biāo)名會(huì)不一樣鏈接時(shí)報(bào) Target not found 的話打開cprConfig.cmake看一眼里面add_library(... IMPORTED)那行寫的是什么名字照著改即可別去改系統(tǒng)文件。對于不用 CMake 的老工程還有一條退路是直接手寫鏈接參數(shù)# 用 curl-config 拿 curl 的鏈接參數(shù)再拼上 cpr 的庫 g main.cpp -I/opt/cpr-1.3.0/include \ -L/opt/cpr-1.3.0/lib -lcpr \ $(curl-config --libs) -lssl -lcrypto -lz -o probe這條命令的每段都有用-I指向 cpr 頭文件-L -lcpr指向庫curl-config --libs把 curl 需要的參數(shù)一次性展開最后三個(gè)是 SSL 和壓縮的顯式依賴。順序很重要庫要放在源文件后面否則 GCC 會(huì)因?yàn)榉?hào)未解析而報(bào)錯(cuò)。4. 工程接入把 cpr 1.3.0 寫進(jìn)業(yè)務(wù)代碼庫裝好了只是開始真正決定這套環(huán)境好不好用的是接入方式。cpr 1.3.0 的 API 設(shè)計(jì)很接近腳本語言的 HTTP 客戶端幾行就能發(fā)請求但也正因?yàn)樘樖秩菀讓懗鰶]有超時(shí)、沒有錯(cuò)誤分支、連接不復(fù)用的代碼上線之后在弱網(wǎng)環(huán)境里表現(xiàn)一塌糊涂。這一章從最小可運(yùn)行例子往外擴(kuò)把參數(shù)取舍講清楚。4.1 最小可編譯的 CMakeLists 與一次 GET先跑通再說別的。下面這段是能編能跑的最小骨架#include cpr/cpr.h #include iostream int main() { // 用本地地址驗(yàn)證避免引入外部依賴 cpr::Response r cpr::Get( cpr::Url{http://127.0.0.1:8080/health}, cpr::Timeout{3000} // 整體超時(shí)單位毫秒 ); // error.code 是傳輸層狀態(tài)status_code 是 HTTP 層狀態(tài)兩者互不替代 if (r.error.code ! cpr::ErrorCode::OK) { std::cerr transport: r.error.message \n; return 2; } std::cout http r.status_code body r.text \n; return 0; }關(guān)鍵在最后那個(gè)判斷。cpr 把兩類失敗分得很清楚r.error記錄的是連接超時(shí)、DNS 失敗、SSL 握手失敗這類傳輸層問題r.status_code記錄的是服務(wù)端返回的 HTTP 狀態(tài)碼。只判斷status_code是新手最常見的疏漏——連接都失敗了status_code是 0業(yè)務(wù)邏輯會(huì)把它當(dāng)成服務(wù)端返回 0處理后面全亂。判斷順序永遠(yuǎn)是先看error.code再看status_code。配套的 CMakeLists 就是 3.4 節(jié)那幾行加上源文件即可。注意別在target_link_libraries里再手動(dòng)補(bǔ)-lcurlcpr::cpr已經(jīng)把傳遞依賴帶上了重復(fù)鏈接在某些平臺(tái)上會(huì)導(dǎo)致符號(hào)重復(fù)定義。4.2 超時(shí)、重試與 SSL 校驗(yàn)的參數(shù)取舍生產(chǎn)代碼和 Demo 的差距基本都在這三個(gè)參數(shù)上。cpr 1.3.0 的超時(shí)是整體超時(shí)不是連接超時(shí)和讀取超時(shí)的分別設(shè)置所以給值的時(shí)候要按業(yè)務(wù)最壞情況考慮。#include cpr/cpr.h #include chrono #include thread #include iostream // 帶退避的簡單重試只對傳輸層失敗重試HTTP 4xx 不重試 cpr::Response GetWithRetry(const std::string url, int max_attempts 3) { cpr::Response r; for (int i 0; i max_attempts; i) { cpr::Session s; s.SetUrl(cpr::Url{url}); s.SetTimeout(cpr::Timeout{2000}); // 單次請求 2 秒 s.SetConnectTimeout(cpr::ConnectTimeout{800}); // 建連單獨(dú)限時(shí) s.SetHeader(cpr::Header{{User-Agent, cpr-1.3.0-probe}}); r s.Get(); if (r.error.code cpr::ErrorCode::OK) { return r; // 傳輸成功就返回HTTP 層交給調(diào)用方判斷 } std::this_thread::sleep_for(std::chrono::milliseconds(200 * (i 1))); } return r; }這段的取舍點(diǎn)有三個(gè)。第一Timeout和ConnectTimeout分開設(shè)建連超時(shí)給得短一些能快速判斷目標(biāo)是否可達(dá)整體超時(shí)留出讀取響應(yīng)的時(shí)間。第二重試只針對傳輸層錯(cuò)誤HTTP 500 這種服務(wù)端明確返回的結(jié)果不重試重試反而可能放大故障。第三退避用線性遞增簡單夠用不需要引入額外依賴。關(guān)于 SSL 校驗(yàn)cpr 提供了cpr::VerifySsl{false}來跳過證書校驗(yàn)。這個(gè)開關(guān)在調(diào)試自簽證書的內(nèi)網(wǎng)服務(wù)時(shí)確實(shí)方便但絕對不要出現(xiàn)在生產(chǎn)代碼里。如果內(nèi)網(wǎng)服務(wù)用的是自簽證書正確做法是把 CA 證書裝進(jìn)系統(tǒng)信任庫或者用cpr::SslOptions指定 CA 路徑而不是關(guān)校驗(yàn)。這條屬于血淚經(jīng)驗(yàn)跳過校驗(yàn)的代碼一旦進(jìn)了主干后面很難再摘出來。4.3 靜態(tài)鏈接與動(dòng)態(tài)鏈接部署時(shí)的取舍裝的時(shí)候BUILD_SHARED_LIBS選哪個(gè)直接決定部署形態(tài)。動(dòng)態(tài)庫的好處是多個(gè)程序共用一份libcpr.so升級時(shí)替換文件即可缺點(diǎn)是部署時(shí)必須帶上.so還得處理RPATH或者設(shè)LD_LIBRARY_PATH。cpr 依賴 curlcurl 又依賴 SSL 和 zlib動(dòng)態(tài)鏈接下這條依賴鏈上任何一環(huán)版本不匹配運(yùn)行期就是一個(gè)symbol lookup error。靜態(tài)庫的好處是產(chǎn)物自包含拷貝一個(gè)可執(zhí)行文件就能跑特別適合分發(fā)小工具或者塞進(jìn)容器鏡像。代價(jià)是體積變大而且必須確保 curl 的靜態(tài)庫也在系統(tǒng)里——很多發(fā)行版的libcurl4-openssl-dev只帶動(dòng)態(tài)庫靜態(tài)庫在單獨(dú)的包里裝漏了會(huì)在鏈接階段報(bào)找不到libcurl.a。我的習(xí)慣是內(nèi)部服務(wù)用動(dòng)態(tài)庫方便統(tǒng)一升級對外分發(fā)的小工具用靜態(tài)庫減少環(huán)境依賴。如果選靜態(tài)安裝 cpr 時(shí)把BUILD_SHARED_LIBS設(shè)為OFF下游鏈接時(shí)確保-lcurl -lssl -lcrypto -lz都能找到靜態(tài)版本。4.4 復(fù)用 Session 而不是每次新建cpr 的cpr::Get這種自由函數(shù)寫法內(nèi)部會(huì)新建一個(gè) Session用完銷毀連接自然也不復(fù)用。在請求量大的場景里這會(huì)明顯拖慢吞吐。改成顯式持有 Session// 長生命周期的 Session復(fù)用連接和 TLS 會(huì)話 cpr::Session session; session.SetUrl(cpr::Url{http://127.0.0.1:8080/api/items}); session.SetTimeout(cpr::Timeout{2000}); session.SetHeader(cpr::Header{{Accept, application/json}}); // 同一個(gè) Session 可以改參數(shù)后重復(fù)調(diào)用 session.SetParameters(cpr::Parameters{{page, 1}, {size, 50}}); cpr::Response first session.Get(); session.SetParameters(cpr::Parameters{{page, 2}, {size, 50}}); cpr::Response second session.Get();要注意 Session 不是線程安全的一個(gè)實(shí)例只能在一個(gè)線程里用。多線程場景下每個(gè)線程各自持有 Session別圖省事搞個(gè)全局共享的那種問題往往在高并發(fā)壓測時(shí)才暴露排查成本很高。5. 常見排查cpr 1.3.0 編譯鏈接的五個(gè)翻車現(xiàn)場這一章按現(xiàn)象 → 原因 → 解決記錄五條實(shí)際遇到過的故障。它們的共同點(diǎn)是報(bào)錯(cuò)信息都不太直觀第一眼容易往錯(cuò)誤的方向猜。5.1 編譯期三類報(bào)錯(cuò)第一條報(bào)fatal error: cpr/generated/cpr_generated_includes.h: No such file or directory?，F(xiàn)象是庫裝了、頭文件路徑也加了就是缺這一個(gè)文件。原因是 1.3.0 的安裝規(guī)則沒有把這個(gè)構(gòu)建時(shí)生成的頭文件一起裝進(jìn)去具體表現(xiàn)隨平臺(tái)和 CMake 版本略有差異。解決就是 3.3 節(jié)那套從構(gòu)建目錄find出來按相對路徑手動(dòng)補(bǔ)到$PREFIX/include/cpr/generated/下補(bǔ)完記得再find一次確認(rèn)。第二條報(bào)大量undefined reference to curl_easy_...?，F(xiàn)象是編譯通過鏈接階段成片報(bào)錯(cuò)。原因是鏈接順序不對或者cpr::cpr的傳遞依賴沒生效。解決是先確認(rèn)用的是target_link_libraries(xxx PRIVATE cpr::cpr)而不是手寫-lcpr手寫的話庫必須放在目標(biāo)文件之后并且補(bǔ)上$(curl-config --libs)。如果還是不行檢查是不是同時(shí)鏈接了系統(tǒng)里另一份 curl。第三條配置階段卡住或者報(bào)下載失敗?，F(xiàn)象是cmake跑到一半長時(shí)間沒動(dòng)靜日志里出現(xiàn)獲取外部源碼的動(dòng)作。原因就是CPR_FORCE_USE_SYSTEM_CURL沒開腳本在嘗試自己弄 curl。解決是回到 3.2 節(jié)把這個(gè)參數(shù)顯式設(shè)為ON然后刪掉構(gòu)建目錄重新配置——注意是刪掉整個(gè)構(gòu)建目錄只改參數(shù)重跑緩存的變量未必能覆蓋干凈。5.2 鏈接與運(yùn)行期兩類報(bào)錯(cuò)第四條運(yùn)行期報(bào) SSL 相關(guān)錯(cuò)誤r.error.message里出現(xiàn)證書驗(yàn)證失敗的字樣?，F(xiàn)象是請求某個(gè) HTTPS 地址一直失敗換 HTTP 就正常。原因是 curl 編譯時(shí)用的 TLS 后端和系統(tǒng)信任庫路徑對不上或者時(shí)間不對導(dǎo)致證書被判定為未生效。解決是先跑curl -V確認(rèn) Features 里有 SSL再用curl -v https://目標(biāo)地址對照排查——如果命令行 curl 也失敗問題在系統(tǒng)層跟 cpr 無關(guān)如果命令行成功而 cpr 失敗檢查鏈接的是不是另一份 curl。第五條程序啟動(dòng)就報(bào)找不到libcpr.so?，F(xiàn)象是編譯鏈接都通過了執(zhí)行時(shí)報(bào)共享庫加載失敗。原因是庫裝在非標(biāo)準(zhǔn)前綴運(yùn)行時(shí)加載器找不到。解決有三個(gè)層次臨時(shí)用LD_LIBRARY_PATH/opt/cpr-1.3.0/lib ./probe驗(yàn)證確認(rèn)是路徑問題長期方案是在 CMake 里設(shè)置INSTALL_RPATH或者把前綴寫進(jìn)/etc/ld.so.conf.d/后跑一次ldconfig。千萬別把LD_LIBRARY_PATH寫進(jìn)全局 shell 配置文件那會(huì)影響同一臺(tái)機(jī)器上所有程序后患無窮。6. 驗(yàn)證跑通三組對照把能跑和跑對分開裝完最忌諱的是編譯通過就完事。我見過太多次編譯沒問題、一上真實(shí)網(wǎng)絡(luò)就出狀況的情況。下面這套驗(yàn)證分三層一層比一層接近真實(shí)使用。第一層靜態(tài)檢查。確認(rèn)四樣?xùn)|西齊全檢查項(xiàng)路徑缺失后果主頭文件/opt/cpr-1.3.0/include/cpr/cpr.h編譯直接失敗生成頭文件/opt/cpr-1.3.0/include/cpr/generated/cpr_generated_includes.h編譯報(bào)找不到文件庫文件/opt/cpr-1.3.0/lib/libcpr.so或.a鏈接失敗CMake 配置/opt/cpr-1.3.0/lib/cmake/cpr/cprConfig.cmakefind_package失敗第二層本地回環(huán)驗(yàn)證。用一個(gè)本地起的小服務(wù)返回固定 JSON跑第 4 章那個(gè)最小例子確認(rèn)status_code是 200、r.text內(nèi)容正確、r.error.code是OK。這一步排除網(wǎng)絡(luò)因素驗(yàn)證的是庫鏈接正確、請求能發(fā)出去。同時(shí)故意請求一個(gè)不存在的端口確認(rèn)r.error.code不是OK且程序走的是錯(cuò)誤分支——錯(cuò)誤分支沒被驗(yàn)證過等于沒寫。第三層真實(shí)環(huán)境驗(yàn)證。挑一個(gè)內(nèi)網(wǎng)的 HTTPS 接口用 Session 復(fù)用方式連發(fā)十次觀察兩件事十次全部成功說明連接復(fù)用和 TLS 會(huì)話沒出問題r.elapsed從第二次開始明顯下降說明連接確實(shí)被復(fù)用了。如果十次耗時(shí)一樣說明每次都在重新建連回去檢查是不是不小心每次都新建了 Session。最后給個(gè)習(xí)慣。從那以后我每次裝完 cpr都會(huì)把這三層驗(yàn)證做成一個(gè)verify.sh留在構(gòu)建目錄里包含路徑檢查、本地回環(huán)請求、十次連發(fā)計(jì)時(shí)三段。原因很簡單這套依賴橫跨編譯器、curl、SSL 三層任何一層動(dòng)過表現(xiàn)都可能變化而人腦記不住上次驗(yàn)證時(shí)的細(xì)節(jié)。腳本跑一遍輸出的三行結(jié)果就是這份環(huán)境還能不能用的黑匣子記錄比回憶靠譜得多。裝環(huán)境這事沒有一勞永逸只有每次都走一遍的后悔藥。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取